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

81–90 of 103 posts

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

#81

Post by magicalhippo »

zinekeller wrote: post #80
ChocolateGod wrote: post #75

Earlier quoted context omitted.

> Windows is orders of magnitude better when it comes to memory management on the desktop compared to Linux. The bar is pretty low, but the windows scheduler is aware what the currently focussed app is so it can prioritise not killing it. On Linux? Not so much.

Actually, it depends on the Windows scheduler settings. On Windows Server, the default is to kill the foreground process (on the assumption that it is just a management app rather than a critical server component).

In either case, Windows tries a lot of things to avoid killing processes. Which at least in a desktop setting is an infinitely better approach than random beheadings without warning.

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

#82

Post by thomashabets2 »

Muromec wrote: post #76
thomashabets2 wrote: post #72

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 so…

>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.

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.

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

#83

Post by yjftsjthsd-h »

LoganDark wrote: post #70
yjftsjthsd-h wrote: post #38

Earlier quoted context omitted.

Yes, 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.

Wayland 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 authentic…

> The most secure system is one that cannot be accessed, technically.

No, security includes Confidentiality, Integrity, and Availability; a lockscreen DoS is a problem

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

#84

Post by StilesCrisis »

hackyhacky wrote: post #36
dooglius wrote: post #33

Earlier quoted context omitted.

The point is that the OOM killer shouldn't exist and arguing about how to tweak it is addressing the wrong problem

I 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?

You 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.

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

#85

Post by AbbeFaria »

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!

Is 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.

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

#86

Post by lokar »

tosti wrote: post #59
lokar wrote: post #50

I 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 d…

Have 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?

No swap device

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

#87

Post by pavon »

loeg wrote: post #43
rwmj wrote: post #28

Earlier quoted context omitted.

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.

Maybe firefox could self-adjust, as a policy?

It looks like it does, which depending on your goal is either helpful or part of the problem. By default processes should inherit their parent's oom_score_adj. If I exit out of firefox completely, then start it up (with no saved tabs), this is the behavior I see:

  $ firefox-esr& PID=$!; choom -p $PID -n 42
  [1] 105360
  pid 105360's OOM score adjust value changed from 0 to 42

  $ for p in $(ps --ppid $PID -opid --no-headers $PID); do printf "%3d" $(
See how each firefox process has a different oom_score_adj with Web Content being more likely to be killed than other processes (233), and none of them have the value that the process was started with (42). This is Firefox 140.11 ESR running on Debian 13.

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

#88

Post by jkrejcha »

thomashabets2 wrote: post #72

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 so…

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

Writing -1000 to /proc//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.

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

#89

Post by jkrejcha »

thomashabets2 wrote: post #82
Muromec wrote: post #76

Earlier quoted context omitted.

>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.

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.

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...

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

#90

Post by jkrejcha »

adgjlsfhk1 wrote: post #57
zinekeller wrote: post #53

Earlier quoted context omitted.

> does fork–exec copy all the process's memory NT: Yes? Why not? (note that this refers to the Windows NT kernel's operation because it had historically a POSIX emulation layer (NT Personalities), not the modern WSL which is just Linux in a Hyper-V)

because this is what causes Windows to use ~80% more memory than unixes

Windows doesn't use fork/exec for process creation in any relevant way today

There are Native APIs for implementing fork (needed for the obsolete POSIX subsystem, primarily), but even on the Native API side, processes are usually spawned through NtCreateProcess or RtlCreateUserProcess, though there is a bunch of setup with regards to the Csr APIs for the Win32 CreateProcess[1]).

[1]: https://stackoverflow.com/a/69605729/2805120

Post reply on HN