linux-kernel - Re: [PATCH v2 06/23] mm: introduce BPF struct ops for OOM handling

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] [day] [month] [year] [list]

Message-ID: <aWU7fnkQ5TLbAUmk@google.com>
Date: Mon, 12 Jan 2026 18:20:46 +0000
From: Matt Bobrowski <mattbobrowski@...gle.com>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
	Alexei Starovoitov <ast@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Michal Hocko <mhocko@...nel.org>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrii Nakryiko <andrii@...nel.org>,
	JP Kobryn <inwardvessel@...il.com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, bpf@...r.kernel.org,
	Martin KaFai Lau <martin.lau@...nel.org>,
	Song Liu <song@...nel.org>,
	Kumar Kartikeya Dwivedi <memxor@...il.com>,
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v2 06/23] mm: introduce BPF struct ops for OOM handling

On Mon, Jan 12, 2026 at 09:20:13AM -0800, Roman Gushchin wrote:
> Matt Bobrowski <mattbobrowski@...gle.com> writes:
> 
> > On Mon, Oct 27, 2025 at 04:17:09PM -0700, Roman Gushchin wrote:
> >> Introduce a bpf struct ops for implementing custom OOM handling
> >> policies.
> >>
> >> ...
> >>
> >> +#ifdef CONFIG_MEMCG
> >> +	/* Find the nearest bpf_oom_ops traversing the cgroup tree upwards */
> >> +	for (memcg = oc->memcg; memcg; memcg = parent_mem_cgroup(memcg)) {
> >> +		bpf_oom_ops = READ_ONCE(memcg->bpf_oom);
> >> +		if (!bpf_oom_ops)
> >> +			continue;
> >> +
> >> +		/* Call BPF OOM handler */
> >> +		ret = bpf_ops_handle_oom(bpf_oom_ops, memcg, oc);
> >> +		if (ret && oc->bpf_memory_freed)
> >> +			goto exit;
> >
> > I have a question about the semantics of oc->bpf_memory_freed.
> >
> > Currently, it seems this flag is used to indicate that a BPF OOM
> > program has made forward progress by freeing some memory (i.e.,
> > bpf_oom_kill_process()), but if it's not set, it falls back to the
> > default in-kernel OOM killer.
> >
> > However, what if forward progress in some contexts means not freeing
> > memory? For example, in some bespoke container environments, the
> > policy might be to catch the OOM event and handle it gracefully by
> > raising the memory.limit_in_bytes on the affected memcg. In this kind
> > of resizing scenario, no memory would be freed, but the OOM event
> > would effectively be resolved.
> 
> I'd say we need to introduce a special kfunc which increases the limit
> and sets bpf_memory_freed. I think it's important to maintain safety
> guarantee, so that a faulty bpf program is not leading to the system
> being deadlocked on memory.

Yeah, I was thinking something along the same lines. We can always add
this kind of new BPF kfunc in at a later point, so need to directly
address this use case right now.