linux-kernel - Re: [PATCH v2 00/23] mm: BPF OOM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251031164844.27060-1-ioworker0@gmail.com>
Date: Sat,  1 Nov 2025 00:48:44 +0800
From: Lance Yang <ioworker0@...il.com>
To: mhocko@...e.com
Cc: akpm@...ux-foundation.org,
	andrii@...nel.org,
	ast@...nel.org,
	bpf@...r.kernel.org,
	cgroups@...r.kernel.org,
	hannes@...xchg.org,
	inwardvessel@...il.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	martin.lau@...nel.org,
	memxor@...il.com,
	roman.gushchin@...ux.dev,
	shakeel.butt@...ux.dev,
	song@...nel.org,
	surenb@...gle.com,
	tj@...nel.org,
	Lance Yang <lance.yang@...ux.dev>
Subject: Re: [PATCH v2 00/23] mm: BPF OOM

From: Lance Yang <lance.yang@...ux.dev>


On Fri, 31 Oct 2025 10:31:36 +0100, Michal Hocko wrote:
> On Mon 27-10-25 16:17:03, Roman Gushchin wrote:
> > The second part is related to the fundamental question on when to
> > declare the OOM event. It's a trade-off between the risk of
> > unnecessary OOM kills and associated work losses and the risk of
> > infinite trashing and effective soft lockups.  In the last few years
> > several PSI-based userspace solutions were developed (e.g. OOMd [3] or
> > systemd-OOMd [4]). The common idea was to use userspace daemons to
> > implement custom OOM logic as well as rely on PSI monitoring to avoid
> > stalls. In this scenario the userspace daemon was supposed to handle
> > the majority of OOMs, while the in-kernel OOM killer worked as the
> > last resort measure to guarantee that the system would never deadlock
> > on the memory. But this approach creates additional infrastructure
> > churn: userspace OOM daemon is a separate entity which needs to be
> > deployed, updated, monitored. A completely different pipeline needs to
> > be built to monitor both types of OOM events and collect associated
> > logs. A userspace daemon is more restricted in terms on what data is
> > available to it. Implementing a daemon which can work reliably under a
> > heavy memory pressure in the system is also tricky.
> 
> I do not see this part addressed in the series. Am I just missing
> something or this will follow up once the initial (plugging to the
> existing OOM handling) is merged?

I noticed that this thread only shows up to patch 10/23. The subsequent
patches (11-23) appear to be missing ...

This might be why we're not seeing the userspace OOM daemon part
addressed. I suspect the relevant code is likely in those subsequent
patches.

Cheers,
Lance