Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)

FreeBSD has a "protect" command which does something similar to what this asks for – the man page [1] describes it:

"The protect command is used to mark processes as protected. The kernel does not kill protected processes when swap space is exhausted. [...] If you protect a runaway process that allocates all memory the system will deadlock."

[1] https://man.freebsd.org/cgi/man.cgi?query=protect&apropos=0&...

It's 2026 and I still can't configure the OOM killer to kill firefox before anything else.

I never pay for the OOF insurance, it seems like a waste of money and I've never met anyone that's had it happen.

I still remember following Andries’s “Linux kernel hacker’s hut” course he taught at the Eindhoven University of Technology (TU/e) back in 2010. Every week we’d get an assignment where we had to write exploits for commonly occurring security vulnerabilities (e.g., buffer overflows, bad printf format). It was one of the most enjoyable courses I ever followed. Thanks for that, Andries!

I confess, this is very funny and the underlying situation is a bit absurd, but it's unclear what point Brouwer is making by pointing out the absurdity.

There surely is something absurd about having to register specific processes as exempt from the OOM killer. But given that the OOM killer exists, and could kill xlock...how should that be fixed?

I’d say, let the one who tried to allocate memory crash, and if you’re a critical process like xlock, use statically allocated memory and don’t alloc again.

Especially in an era where RAM is so expensive, the obvious answer is to simply never use memory. If your data can't fit in the plethora of CPU registers at your disposal, your software is probably too complicated. /s

(2004)