[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v7jz3smj.fsf@linux.dev>
Date: Tue, 28 Oct 2025 09:20:36 -0700
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Chris Mason <clm@...a.com>
Cc: bot+bpf-ci@...nel.org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, ast@...nel.org, surenb@...gle.com,
mhocko@...nel.org, shakeel.butt@...ux.dev, hannes@...xchg.org,
andrii@...nel.org, inwardvessel@...il.com, linux-mm@...ck.org,
cgroups@...r.kernel.org, bpf@...r.kernel.org, martin.lau@...nel.org,
song@...nel.org, memxor@...il.com, tj@...nel.org,
daniel@...earbox.net, eddyz87@...il.com, yonghong.song@...ux.dev,
ihor.solodrai@...ux.dev
Subject: Re: [PATCH v2 14/23] mm: allow specifying custom oom constraint for
BPF triggers
Chris Mason <clm@...a.com> writes:
> On 10/27/25 7:48 PM, bot+bpf-ci@...nel.org wrote:
>>> @@ -1350,11 +1367,14 @@ __bpf_kfunc int bpf_oom_kill_process(struct oom_control *oc,
>>> * Returns a negative value if an error occurred.
>>> */
>>> __bpf_kfunc int bpf_out_of_memory(struct mem_cgroup *memcg__nullable,
>>> - int order, u64 flags)
>>> + int order, u64 flags,
>>> + const char *constraint_text__nullable)
>>> {
>>> struct oom_control oc = {
>>> .memcg = memcg__nullable,
>>> .order = order,
>>> + .constraint = CONSTRAINT_BPF,
>>> + .bpf_constraint = constraint_text__nullable,
>>> };
>>> int ret;
>>
>> When CONSTRAINT_BPF is set in bpf_out_of_memory(), the early return in
>> constrained_alloc() prevents oc->totalpages from being initialized. This
>> leaves totalpages at zero (from the designated initializer).
>>
>> Later in the call chain out_of_memory()->select_bad_process()->
>> oom_evaluate_task()->oom_badness(), the code performs division by
>> totalpages at line 237:
>>
>> adj *= totalpages / 1000;
>>
>> Can this cause a division by zero? The path is reachable when a BPF
>> program calls bpf_out_of_memory() and either no BPF OOM handler is
>> registered or the handler fails to free memory, causing execution to fall
>> through to select_bad_process().
>
> Looks like the AI got a little excited about finding the uninit variable
> chain and forgot what dividing by zero really means. I'll add a false
> positive check for this.
Yup, it was *almost* correct :)
But overall I'm really impressed: it found few legit bugs as well.
The only thing: I wish I could run it privately before posting to
public mailing lists...
Thanks,
Chris!
Powered by blists - more mailing lists