Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lwn.net

Post reply on HN
Print view View original

21–30 of 103 posts

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

#22

Post by SoftTalker »

LoganDark wrote: post #3
sedatk wrote: post #2

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.

This is only a viable answer when overcommit is disabled. The problem comes when overcommit is enabled and you find yourself in a position where many programs think they already have memory and yet there is none to give them. If you simply kill the first piece of code that encounters the end of available memory you might take down anything including the kernel itself. Nothing like statically allocating memory can wor…

OOM killer always felt like a band-aid on a severed artery to me. I've rarely seen a machine that got into OOM state really recover without a full reboot.

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

#23

Post by blux »

EdSchouten wrote: post #19

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!

Hey fellow TU/e'er :) I followed his course as well, somewhere around 2004/5. Executing man in the middle attacks, writing buffer overflow exploits. Good memories!

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

#25

Post by bellowsgulch »

rwmj wrote: post #13

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

I looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj...

So, in actuality, I think your assertion just taught us all something, because despite knowing that the OOM killer and that the Magic SysRq key[1] exists, I didn't know you could configure this as an input!

[1]: https://en.wikipedia.org/wiki/Magic_SysRq_key

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

#26

Post by hyperpape »

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?

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

#28

Post by rwmj »

bellowsgulch wrote: post #25
rwmj wrote: post #13

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

I looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj... So, in actuality, I think your assertion just taught us all something, because despite knowing that the OOM killer and that the Magic SysRq key[1] exists, I didn't know you could configure this as an input! [1]: https://en.wikipedia.org/wiki/Magic_SysRq_key

I'm aware of it, but it's awkward to use in practice. You have to track down all the FF processes, each time you run it, and adjust all their scores.
Post reply on HN