linux-kernel - Re: [PATCH v2 15/23] mm: introduce bpf_task_is_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: <aQEMG508sUQWDGrn@slm.duckdns.org>
Date: Tue, 28 Oct 2025 08:31:55 -1000
From: Tejun Heo <tj@...nel.org>
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>
Subject: Re: [PATCH v2 15/23] mm: introduce bpf_task_is_oom_victim() kfunc

Hello,

On Tue, Oct 28, 2025 at 11:09:28AM -0700, Roman Gushchin wrote:
> > In general, I'm not sure it's a good idea to add kfuncs for things which are
> > trivially accessible. Why can't things like this be provided as BPF
> > helpers?
> 
> I agree that this one might be too trivial, but I added it based on the
> request from Michal Hocko. But with other helpers (e.g. for accessing
> memcg stats) the idea is to provide a relatively stable interface for
> bpf programs, which is not dependent on the implementation details. This
> will simplify the maintenance of bpf programs across multiple kernel
> versions.

This is an abstract subject and thus a bit difficult to argue concretely.
I'll just share my take on it based on my experience w/ sched_ext.

The main problem with "I'll add enough interfaces to keep the BPF programs
stable" is that it's really difficult to foresee how BPF programs will
actually use them. You may have certain ideas on what information they would
consume and how but other people may have completely different ideas. After
all, that's why we want this to be BPF defined.

Projecting to the future, there's a pretty good chance that some programs
will be using mix of these hard coded interfaces and other generic BPF hooks
and mechanisms. At that point, when you want to add access to something new,
the decision becomes awakward. Adding a new hard coded interface doesn't
really enable anything that isn't possible otherwise while creating
compatibility problems for older kernels.

The other side of that coin is that BPF has a lot of mechanisms that support
backward and forward binary compatibility such as CO-RE relocations,
polymorhpic struct_ops and kfunc matching, type-aware symbol existence
testing and so on. It really is not that difficult to maintain a pretty
large sliding window of compatibility using these mechanisms and I believe
concerns over interface stability is overblown.

So, my take is that trying to bolster interface stability doesn't really
solve serious enough problems that justify the downsides of adding those
hard coded interface. There are just better and more flexible ways to deal
with them.

Thanks.

-- 
tejun