[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9a2c5f29-b45c-4ff3-a8f4-51d207a82d38@linux.dev>
Date: Tue, 27 Jan 2026 12:21:03 -0800
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Michal Hocko <mhocko@...e.com>, Alexei Starovoitov <ast@...nel.org>,
Matt Bobrowski <mattbobrowski@...gle.com>,
Shakeel Butt <shakeel.butt@...ux.dev>, JP Kobryn <inwardvessel@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Suren Baghdasaryan <surenb@...gle.com>, Johannes Weiner
<hannes@...xchg.org>, Andrew Morton <akpm@...ux-foundation.org>,
bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v3 08/17] mm: introduce bpf_oom_kill_process()
bpf kfunc
On 1/26/26 6:44 PM, Roman Gushchin wrote:
> +static int bpf_oom_kfunc_filter(const struct bpf_prog *prog, u32 kfunc_id)
The filter callback is registered for BPF_PROG_TYPE_STRUCT_OPS. It is
checking if a kfunc_id is allowed for other struct_ops progs also, e.g.
the bpf-tcp-cc struct_ops progs.
> +{
> + if (prog->type != BPF_PROG_TYPE_STRUCT_OPS ||
> + prog->aux->attach_btf_id != bpf_oom_ops_ids[0])
> + return -EACCES;
The 'return -EACCES' should be the cause of the "calling kernel function
XXX is not allowed" error reported by the CI. Take a look at
btf_kfunc_is_allowed().
Take a look at bpf_qdisc_kfunc_filter(). I suspect it should be
something like this, untested:
if (btf_id_set8_contains(&bpf_oom_kfuncs, kfunc_id) &&
prog->aux->st_ops != &bpf_oom_bpf_ops)
return -EACCES;
return 0;
> +
> +static const struct btf_kfunc_id_set bpf_oom_kfunc_set = {
> + .owner = THIS_MODULE,
> + .set = &bpf_oom_kfuncs,
> + .filter = bpf_oom_kfunc_filter,
> +};
> +
> +static int __init bpf_oom_init(void)
> +{
> + int err;
> +
> + err = register_btf_kfunc_id_set(BPF_PROG_TYPE_STRUCT_OPS,
> + &bpf_oom_kfunc_set);
Powered by blists - more mailing lists