6 ms·
Re: [PATCH] OOM_pardon, a.k.a. don't kill my xlock (2004)
- sedatk 4mo agoI’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.
- LoganDark 4mo agoThis 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 work when overcommit is enabled because the kernel is free to compress memory, page it out and etc. and then murder you the next time you try to perform any operation that it doesn't have the space for, no matter how safe and static your initialization was. Note that overcommit is very useful in many cases including the ones where swap saves the stability of the system under conditions that would otherwise completely lock up or panic, so it's also not viable to just prevent it from being used.
- sedatk 4mo agoI’m not against taking down the kernel if the situation is that catastrophic. Better than killing the lock screen for sure.
- LoganDark 4mo agoIMO if the security of a system depends on the lock screen not crashing then the system is not very secure. Security protocols should never fail open like that; a lock screen should never simply be a layer on top of the authenticated desktop. Windows and macOS get this right. I believe Wayland display managers are also able to get this right (but I haven't checked).
- yjftsjthsd-h 4mo agoYes, Wayland should fix this. Granted, then you have a locked screen that the user may or may not be able to unlock, which is awkward if better.
- LoganDark 4mo agoWayland the protocol already fixes this -- there's nothing that exactly requires a display manager to not have a completely separate desktop for the unauthenticated state, where a trusted application (or the display manager itself) can accept credentials in order to authorize a transition to the authenticated state, and where a crash of the trusted application or lock screen does not result in access to the authenticated state. I just dunno if anyone does that yet. I'm sure somebody must have... > Granted, then you have a locked screen that the user may or may not be able to unlock, which is awkward if better. The most secure system is one that cannot be accessed, technically. In some cases it's better not to let anybody in than to let an attacker in (technically). Of course, this is frustrating for the user.
- yjftsjthsd-h 4mo ago> The most secure system is one that cannot be accessed, technically. No, security includes Confidentiality, Integrity, and Availability; a lockscreen DoS is a problem
- LoganDark 4mo agoYes, a DoS is a problem, but it doesn't let an attacker in. Like, if an employee of a company can't get through their lock screen to access a confidential shared server, that is far less bad than an attacker downloading the entire server and leaking it online. But yes, of course, if suddenly no employees could get through their lock screens, that would still be quite bad -- but it only takes one attacker getting in to cause damage.
- account42 4mo agoDepending on the implementation and exactly which component crashed, you may still unlock the session from the console in a different VT.
- josefx 4mo agoShouldn't desktop environments detect if a lock screen terminated abnormaly anyway? The OOM killer is just one of many possible causes.
- deleted 4mo ago[deleted]
- SoftTalker 4mo agoOOM 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.
- sph 4mo agoWhy would a system break if you SIGKILL a process? I’ve seen plenty of server log with OOM killing mariadb processes, and then being restarted automatically by systemd, often with no one noticing if not days later. The thing that bogs down systems and often makes them unrecoverable is when a memory hungry process starts swapping. Good luck trying to SSH in. Swap is such a silly idea on servers - good to deal with pages no one accesses, catastrophic when you’re out of RAM and memory latencies suddenly become 4 or 5 orders of magnitude slower.
- feelamee 4mo ago> if you’re a critical process like xlock, use statically allocated memory and don’t alloc again. This doesn't save you if someone other allocates and OOM killer chooses you as victim
- hkolk 4mo agoWhat is proposed is to not have an OOM killer with a selection process, meaning that the "someone other allocates" would be the one dying.
- sedatk 4mo agoYes, don’t have OOM roulette.
- silon42 4mo agoAt least for processes that don't overcommit...
- tux3 4mo agoThe problem is that Linux has memory overcommit and it will OOM when a process faults a page in, not just when someone allocates memory. So the OOM condition can hit any random process, not necessarily one that just tried to allocate. If you don't have some sort of selection, then you would still have an OOM killer, only it will be killing completely at random.
- muvlon 4mo agoThat's true, but critical processes could mlockall() after setup, so their stuff never needs paging in.
- Retr0id 4mo agoStatically allocated memory can still OOM on access, due to overcommit and lazy page table population. What you really want is mlockall(2) (probably with MCL_CURRENT|MCL_ONFAULT followed by madvise with MADV_POPULATE_*)
- Retr0id 4mo agooops MCL_ONFAULT kinda does the opposite of what I wanted - I think if you omit that you can skip the madvise, and mlockall will populate everything for you.
- amluto 4mo agoThe fact that xlock crashing unlocks an X11 session is, IMO, pathetic.
- cwillu 4mo ago(2004)
- jml7c5 4mo agoThanks. I was confused for a bit, given these days you can do echo "-1000" > /proc/<pid>/oom_score_adj to disable OOM killing for a process. https://github.com/torvalds/linux/blob/master/include/uapi/linux/oom.h https://github.com/torvalds/linux/blob/master/include/uapi/l...
- cwillu 4mo agoThere's also /proc/sys/vm/panic_on_oom and /proc/sys/vm/oom_kill_allocating_task for other behaviours suggested in the comments.
- rwmj 4mo agoIt's 2026 and I still can't configure the OOM killer to kill firefox before anything else.
- dvh 4mo agoThis. It's always browser running amok. I configured win+k shortcut key to: killall -9 chrome
- SoftTalker 4mo agoI always wanted it to target java processes, as they were always the culprit. These days it's python, VSCode, and antigravity.
- bellowsgulch 4mo agoI looked into this, and actually, it seems like maybe you can? https://man7.org/linux/man-pages/man5/proc_pid_oom_score_adj.5.html 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 https://en.wikipedia.org/wiki/Magic_SysRq_key
- rwmj 4mo agoI'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.
- loeg 4mo agoMaybe firefox could self-adjust, as a policy?
- rwmj 4mo agoYes this would be nice. Or maybe the OOM system would have two other files, /sys/oom/kill_first and /sys/oom/kill_never which would solve the problem more directly for the majority of cases. I should really send a patch rather than complaining ...
- EdSchouten 4mo agoI 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!
- blux 4mo agoHey 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!
- AbbeFaria 4mo agoIs this course still available? What about the course materials? I know it will be dated but if so can someone pls share the links. Tried searching for it on google but couldn’t find it.
- EdSchouten 4mo agoIt looks like the code of the course was 2WC16. Unfortunately the course material no longer seems to be available online.
- lelandfe 4mo agoI never pay for the OOF insurance, it seems like a waste of money and I've never met anyone that's had it happen.
- keyle 4mo agoIt can only happen once anyway, and I fly weekly!
- hyperpape 4mo agoI 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?
- dooglius 4mo agoThe point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem
- hackyhacky 4mo agoI agree that that's the point he's making, but I don't see how that would work practically. His attitude is that malloc(1<<63) should immediately crash the system, every time? How is that better?
- cpgxiii 4mo agoNo, if a process allocates an infeasible amount, malloc fails and the process needs to deal with the failure (which is what already happens, "malloc doesn't fail on Linux" is only really true for smaller-than-page-size allocations). The point being made is that the system should account conservatively for all memory that can be used, not just the optimistic underestimate that overcommit enables (i.e. the plane should always carry enough fuel for contingencies, and landing with extra fuel is a good outcome).
- StilesCrisis 4mo agoYou never need to crash the system if you remove overcommit. You just crash the one process. Practically speaking, you don't even need to crash here; you just return null (which malloc is always free to do) and let the consequences speak for themselves.
- jkrejcha 4mo agomalloc can just return NULL (in specific, mmap returns -ENOMEM and your libc translates that). Applications need to check for success anyway
- bastawhiz 4mo agoEspecially 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
- throwaway87543 4mo agoI see you are an AMD VCACHE enjoyer.
- ptx 4mo agoFreeBSD 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&sektion=0&manpath=FreeBSD+15.0-STABLE&format=html https://man.freebsd.org/cgi/man.cgi?query=protect&apropos=0&...
- nemothekid 4mo agoWhile I have had my time fighting the OOM killer, I believe overcommit would have always won. To torture the metaphor a bit more, airlines have OOF mechanism - they just eject the overcommitted passengers before the plane takes off. A passenger buying a ticket is malloc(), but passengers don't always utilize the seat (use the memory). Normally this works out fine, but occasionally, there are too many passengers. Thankfully though instead of executing a couple passengers they give you a voucher.
- jkrejcha 4mo agoI've mentioned this elsewhere in the thread, but I think it's a difference of view on what malloc represents. Operating systems do have "reserve this part of the address space" APIs and these reservations don't get charged against your commit because you're simply reserving the space, not committing to using it, and so the operating system doesn't need to back it with anything. In this worldview, malloc is like me buying a plane ticket at the counter for a specific flight that's going to leave soon. I'd be really annoyed if I were bumped off a flight I just paid for (and would've rather been told "that flight is full, try again later" (malloc returns NULL)). This is, for example what Windows does. Under memory pressure, it'll say to applications, "hey no I'm not in a giving mood for memory right now" (and will sometimes bump the size of the pagefile if configured to do this, but only up to a point). The thought behind this is that well... applications have to handle malloc returning NULL anyway. Whether that's calling abort and giving up is one matter, another might be to retry the allocation at a later time (maybe after Windows has bumped the pagefile size), another might be to handle an error using some preallocated buffer or whatever.
- lokar 4mo agoI know this is not a popular / mainstream position, but I managed a very large fleet of systems this way: - no system swap - enough memory for core system services set aside in a cgroup for them to use - by default, all prod service binaries load all code pages into ram at start, and lock them in (no paging out code pages at runtime) - if needed (rare) services can mount some swap in their own cgroup, but very much discouraged You need to know how much ram you are going to use, and actually stick to that. Very little is wasted in practice, and you don't have to deal with OOMs all the time. Everything is much more predictable.
- xyzzy_plugh 4mo agoI agree with your perspective. I certainly agree that swap can be invaluable at times, and is generally a mistake for your run-of-the-mill production services. It's a nice approach particularly because all OOMs become actionable: there's a bug in a service or a limit is wrong or traffic is changing in an unexpected way. Systems built this way end up being extremely reliable in my experience. It's an uphill battle both ways though and not everyone is up for that experience.
- tosti 4mo agoHave you disabled swap in the kconfig entirely? If not, is your vm.swapiness 0? How do you deal with overcommit? Did you replace malloc with a more strict implementation?
- mad_vill 4mo agoHappy to see this trending, I probably share this in my company's slack once a month.
- thomashabets2 4mo agoHey, 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/ https://lwn.net/Articles/104179/
- Muromec 4mo ago>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 4mo agoSure. 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 4mo agoIt 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-stability-with-this-one-weird-trick/ https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...
- deleted 4mo ago[deleted]