linux-kernel - Re: [PATCH bpf-next v3 00/17] 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: <87zf5x1tqx.fsf@linux.dev>
Date: Wed, 28 Jan 2026 10:23:34 -0800
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Michal Hocko <mhocko@...e.com>,  bpf <bpf@...r.kernel.org>,  Alexei
 Starovoitov <ast@...nel.org>,  Matt Bobrowski <mattbobrowski@...gle.com>,
  Shakeel Butt <shakeel.butt@...ux.dev>,  JP Kobryn
 <inwardvessel@...il.com>,  LKML <linux-kernel@...r.kernel.org>,  linux-mm
 <linux-mm@...ck.org>,  Suren Baghdasaryan <surenb@...gle.com>,  Johannes
 Weiner <hannes@...xchg.org>,  Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH bpf-next v3 00/17] mm: BPF OOM

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Wed, Jan 28, 2026 at 12:06 AM Michal Hocko <mhocko@...e.com> wrote:
>>
>>
>> > Another viable idea (also suggested by Andrew Morton) is to develop
>> > a production ready memcg-aware OOM killer in BPF, put the source code
>> > into the kernel tree and make it loadable by default (obviously under a
>> > config option). Myself or one of my colleagues will try to explore it a
>> > bit later: the tricky part is this by-default loading because there are
>> > no existing precedents.
>>
>> It certainly makes sense to have trusted implementation of a commonly
>> requested oom policy that we couldn't implement due to specific nature
>> that doesn't really apply to many users. And have that in the tree. I am
>> not thrilled about auto-loading because this could be easily done by a
>> simple tooling.
>
> Production ready bpf-oom program(s) must be part of this set.
> We've seen enough attempts to add bpf st_ops in various parts of
> the kernel without providing realistic bpf progs that will drive
> those hooks. It's great to have flexibility and people need
> to have a freedom to develop their own bpf-oom policy, but
> the author of the patch set who's advocating for the new
> bpf hooks must provide their real production progs and
> share their real use case with the community.
> It's not cool to hide it.

In my case it's not about hiding, it's a chicken and egg problem:
the upstream first model contradicts with the idea to include the
production results into the patchset. In other words, I want to settle
down the interface before shipping something to prod.

I guess the compromise here is to initially include a bpf oom policy
inspired by what systemd-oomd does and what is proven to work for a
broad range of users. Policies suited for large datacenters can be
added later, but also their generic usefulness might be limited by the
need of proprietary userspace orchestration engines.

> In that sense enabling auto-loading without requiring an end user
> to install the toolchain and build bpf programs/rust/whatnot
> is necessary too.
> bpf-oom can be a self contained part of vmlinux binary.
> We already have a mechanism to do that.
> This way the end user doesn't need to be a bpf expert, doesn't need
> to install clang, build the tools, etc.
> They can just enable fancy new bpf-oom policy and see whether
> it's helping their apps or not while knowing nothing about bpf.

Fully agree here. Will implement in v4.

Thanks!