Re: [PATCH v2 08/23] mm: introduce BPF kfuncs to deal with memcg pointers

[Chris Mason]

On 10/28/25 1:12 PM, Alexei Starovoitov wrote:
> On Tue, Oct 28, 2025 at 9:11 AM Roman Gushchin <roman.gushchin@xxxxxxxxx> wrote:
>>
>> bot+bpf-ci@xxxxxxxxxx writes:
>>
>>> ```
>>> commit ec8e2e1769704b4f69261f36e6aaf035d47c5f0f
>>> Author: Roman Gushchin <roman.gushchin@xxxxxxxxx>
>>> Can this dereference a NULL css pointer?  The function checks css for
>>> NULL at line 42 with "if (css && css_tryget(css))", which suggests css
>>> can be NULL.  If a BPF program calls this function with a NULL css,
>>> wouldn't it crash here before reaching that check?
>>
>> Here css passed as an argument to bpf_get_mem_cgroup() can't be NULL,
>> because the BPF verifier guarantees that it's a valid css pointer.
>>
>> However the result of rcu_dereference_raw(cgroup->subsys[ssid]) can be
>> NULL, this is why the "if (css && css_tryget(css))" check is required
>> down below.
> 
> Yeah. Not sure how feasible it is to teach AI about KF_RCU semantics.

I pulled it down locally to try and w/semcode it is properly catching this:

False Positives Eliminated

1. EH-001 NULL dereference - css parameter dereferenced without check

- Why false positive: BPF verifier ensures pointer parameters are
non-NULL. All kernel kfuncs follow the same pattern of not checking
parameters for NULL (css_rstat_updated, css_rstat_flush,
bpf_put_mem_cgroup, etc.). The KF_RET_NULL flag controls return value,
not parameter nullability.

My plan is to just have the prompt read Documentation/bpf/kfuncs.rst,
which Eduard suggested.  I'll make a bpf kfuncs pattern and do that.

-chris