[thomashabets2]

Hey, that's me! (suggesting an OOM pardon feature)

It's a funny reply. But what was not funny was the OOM killer killing my screen locker.

Joke all you want, but 22 years later I still stand by that I'd rather get a kernel panic than kill the screen lock.

These days you can do oom score adjusting, which is not as strong as a pardon. I may be taking too much credit, and may misremember the timeline, but I feel like someone took my crappy kernel patch and went "fine, I'll do it the right way", merged that oom score adjusting maybe a year or so later.

Here's an LWN article about it, too: https://lwn.net/Articles/104179/

[jkrejcha]

> These days you can do oom score adjusting, which is not as strong as a pardon.

Writing -1000 to /proc/<pid>/oom_score_adj will cause the OOM killer not to consider the process at all :)

From the man page proc_pid_oom_score_adj(5)

> The value of oom_score_adj is added to the badness score before it is used to determine which task to kill. Acceptable values range from -1000 (OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). [...]. The lowest possible value, -1000, is equivalent to disabling OOM-killing entirely for that task, since it will always report a badness score of 0.

[creatonez]

The modern desktops seem to have some way to jam themselves if the lock screen fails.

For example, KDE: https://preview.redd.it/plasma-lock-screen-messed-up-v0-zx7h...

GNOME: https://forums.freebsd.org/attachments/index-jpeg.8571/

I think this only works because there is top-down integration between the different parts. The compositor knows when it's supposed to be locked. Whereas the old screen lockers were just very aggressive Xorg apps that suffer from "What if two programs did this?" problems (https://devblogs.microsoft.com/oldnewthing/20110310-00/?p=11...)

[Muromec]

>Joke all you want, but 22 years later I still stand by that I'd rather get a kernel panic than kill the screen lock.

An argument can be made that the kernel should not cover for architectural missteps of the X server and that X server should be the one to crash when it's security-critical component was killed for whatever reason.

[thomashabets2]

Sure. But that's not where we are.

Also there are other safety and security critical reasons why you'd want to exempt some processes.

Arguably (and it definitely has been argued) the real architectural misstep is the Linux kernel overcommitting by default in the first place.

[jkrejcha]

It has also created this unfortunate assumption a lot of the time that malloc and friends are (infallible OR crash) and, separately, can sometimes have potentially weird tendencies to force undefined behaviors on otherwise well-defined programs (I think primarily around mmap, although I'm not remembering the details super well).

Agreed though, overcommit is the culprit here. I get why it happened (unfortunate consequences of fork and friends existing as the way to spawn tasks and wanting those to be both performant and not fail in frustrating conditions), but I don't think it was a design that aged particularly well.

I actually like somewhat the notion of how Windows handles these two things

1. For address space reservations, you can reserve address space but in order to touch it you have to commit it. Commits have to be backed by something (RAM, a file, pagefiles if they exist) and if a commit fails, they'll get NULL back from malloc. It allows code to be more correct in the face of low-memory conditions or to try again later (Firefox for example, does this[1] on Windows).

2. Process creation is done with a specific API to create processes. The only problem with this I think is that you have to specify everything at creation time, but you could augment this by creating processes in a stopped state (iirc Linux has to do this anyway to set up some stuff before it can hand over control back to userland) and having the parent send FDs to the child or whatnot. Windows... doesn't do this, it has a couple of kitchen sink APIs for creating processes and setting up stuff like the standard streams... in any case I'm getting off topic.

Don't think there's much about that design that can be changed now though

[1]: https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...