linux-kernel - Re: [RFC PATCH 1/2] mm, oom: Introduce bpf_select

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]

Date:   Tue, 22 Aug 2023 14:42:09 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Chuyi Zhou <zhouchuyi@...edance.com>
Cc:     Roman Gushchin <roman.gushchin@...ux.dev>, hannes@...xchg.org,
        ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        muchun.song@...ux.dev, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org, wuyun.abel@...edance.com,
        robin.lu@...edance.com
Subject: Re: [RFC PATCH 1/2] mm, oom: Introduce bpf_select_task

[Still catching up with older threads. Sorry for the late reply]
On Mon 14-08-23 19:25:08, Chuyi Zhou wrote:
> Hello,
> 
> 在 2023/8/9 15:53, Michal Hocko 写道:
> > On Tue 08-08-23 14:41:17, Roman Gushchin wrote:
[...]
> > > It would be also nice to come up with some practical examples of bpf programs.
> > > What are meaningful scenarios which can be covered with the proposed approach
> > > and are not covered now with oom_score_adj.
> > 
> Just like Abel said, the oom_score_adj only adjusts the memory usage-based
> decisions, and it's hard to be translated into other semantics. We see that
> some userspace oom-killer like oomd has implemented policies based on other
> semantics(e.g., memory growth, priority, psi pressure, ect.) which can be
> useful in some specific scenario.

Sure, I guess we do not really need to discuss that oom_score_adj is not
a great fit ;) We want to have practical (read no-toy) oom policies that
are useful as a PoC though.

> > Agreed here as well. This RFC serves purpose of brainstorming on all of
> > this.
> > 
> > There is a fundamental question whether we need BPF for this task in the
> > first place. Are there any huge advantages to export the callback and
> > allow a kernel module to hook into it?
> 
> If we export the callback to a kernel module and hook into it,
> We still have the same problems (e.g., allocating much memory). Just like
> Martin saied, at least BPF supports some basic running context and some
> unsafe behavior is restricted.

I do not follow. Kernel module has access to any existing kernel
interfaces without any need to BPF them. So what exactly is the strength
of the BPF over kernel module hook? I am pretty sure there are some
(many?) but it is really important to be explicit about those before we
make any decision.

-- 
Michal Hocko
SUSE Labs