The search for the correct amount of split-lock misery [LWN.net]

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 11:52 UTC (Fri) by Vipketsh (guest, #134480)
In reply to: The search for the correct amount of split-lock misery by marcH
Parent article: The search for the correct amount of split-lock misery

If you are only ever looking to make the future good, the present will *always* suck.

Is there any known exploit using this scenario to guard against ? I mean, users shouldn't go off and install random "break my machine" programs or if they do DoS-ing an individual's machine isn't exactly beneficial, nor is it the worst that an evil application can do.

I see this change and behaviour as more inline with the seemingly recent trend that the linux kernel is to do well out-of-the-box for cloud-based deployments, and only as a second concession allow individuals to tweak things so their single-user laptops and systems may work reasonably. A little sad and quite backwards since cloud operators have lots of talent on hand to tweak and analyse their systems (and they do anyway) with which individuals can't hope to compete.

to post comments

The search for the correct amount of split-lock misery

Posted Oct 28, 2022 22:18 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> If you are only ever looking to make the future good, the present will *always* suck.

Actually, by stalling abusive applications this improves the present of other applications too. Single app gaming really does not feel like a top Linux use case today. Unless you're counting ChromeOS, Android and Steam deck but then you're not administering your own system and you can count on its admins to optimize all this for you.

> Is there any known exploit using this scenario to guard against ?

This is not just about intentional abuse but also about performance under unintentional abuse too.

> recent trend that the linux kernel is to do well out-of-the-box for cloud-based deployments, and only as a second concession allow individuals

As already explained elsewhere this is not just about multi-user but about multi process in general.

The search for the correct amount of split-lock misery

Posted Oct 29, 2022 2:30 UTC (Sat) by Vipketsh (guest, #134480) [Link]

> by stalling abusive applications this improves the present of other applications too

In theory I understand, but do you or anyone else have any numbers to the magnitude of this slowdown on, say, a typical 4/8 core laptop ? Theoretical problems should always be trumped by practical breakage, until proven otherwise.

This is like arguing that some application causing heavy contention on a kernel lock is a DoS attack or, if not that, the application is slowing down the system and thus the kernel should prevent it from running. Clearly this is madness. How are split locks any different ?

> also about performance under unintentional abuse too.

The malicious case is all that matters. For everything else, one of two possible outcomes is possible: (i) the performance issue is fixed and so is not a problem or (ii) the performance issue is not fixed in which case the choices are "slow(er) system" and "program does not work". A slower system is *always* preferred to a non working one and that is doubly true for machines of individuals.

Also let's not forget that this case is only relevant to x86 -- the risc machines (arm & riscv) not only don't support this feature but often don't support *any* unaligned access, atomic or otherwise. With their rise in popularity there will practically not be any cases of this in opensource and with propriety apps the question is that it works or not and working is always preferred.