Messages in this thread | | | Date | Sun, 30 Oct 2022 16:13:15 +0000 | From | Lukas Straub <> | Subject | Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to avoid userspace regression |
| |
On Thu, 29 Sep 2022 15:37:55 +0000 "Luck, Tony" <tony.luck@intel.com> wrote:
> >> I have a revert removing the misery ready and tested, let me know if I > >> should submit it. > > > > I'm a bit of a late arrival to the split lock party, so I'm a bit > > hesitant to merge any changes immediately. > > > > How about we give it a few weeks and see if the current behavior impacts > > anyone else? Maybe the best route will be more clear then. > > Applying "misery" to the processes that are executing split-lock flows saves > the rest of the system from a different level of misery (for the duration of the > split lock other logical CPUs and I/O devices have access to memory blocked). > > So the "misery" serves a very useful purpose on multi-user systems.
Hello Everyone, How about the following: The kernel traps the split-lock, but instead of punishing the process artificially it emulates it in a different way that won't harm the system as a whole. Of course this still will be slower than a non-split-lock but surely won't take 10ms.
For example, you could emulate the instruction without atomic semantics, but protected under a single global mutex for all split-lock operations instead. This is how atomics are done on on alpha AFAIK, which doesn't have atomic instructions.
This is not as simple as the current solution. But I see the current solution more like a quick and dirty workaround for this security/DoS issue, until a proper solution (like my proposal) is implemented.
Regards, Lukas Straub
> Maybe the decision of which mode to use could be dynamic based on > number of online CPUs? Laptops/desktops with low counts (<50???) > could just "warn", while servers could default to the "seq" mode. > > Or perhaps there is some other heuristic to distinguish single-user > systems where the split-locks are not causing pain to other users? > > -Tony
--
[unhandled content-type:application/pgp-signature] | |