[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b099a95e-5e69-4eeb-a2c9-9a52b8042a85@linux.dev>
Date: Fri, 9 Jan 2026 12:02:21 -0800
From: Ihor Solodrai <ihor.solodrai@...ux.dev>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
<eddyz87@...il.com>, Mykyta Yatsenko <yatsenko@...a.com>,
Tejun Heo <tj@...nel.org>, Alan Maguire <alan.maguire@...cle.com>,
Benjamin Tissoires <bentiss@...nel.org>, Jiri Kosina <jikos@...nel.org>,
bpf <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
sched-ext@...ts.linux.dev
Subject: Re: [PATCH bpf-next v1 08/10] bpf: Add bpf_task_work_schedule_*
kfuncs with KF_IMPLICIT_ARGS
On 1/9/26 11:58 AM, Alexei Starovoitov wrote:
> On Fri, Jan 9, 2026 at 10:50 AM Ihor Solodrai <ihor.solodrai@...ux.dev> wrote:
>>
>> +__bpf_kfunc int bpf_task_work_schedule_signal(struct task_struct *task, struct bpf_task_work *tw,
>> + void *map__map, bpf_task_work_callback_t callback,
>> + struct bpf_prog_aux *aux)
>> +{
>> + return bpf_task_work_schedule(task, tw, map__map, callback, aux, TWA_SIGNAL);
>> +}
>> +
>> __bpf_kfunc int bpf_task_work_schedule_signal_impl(struct task_struct *task,
>> struct bpf_task_work *tw, void *map__map,
>> bpf_task_work_callback_t callback,
>> void *aux__prog)
>> {
>> - return bpf_task_work_schedule(task, tw, map__map, callback, aux__prog, TWA_SIGNAL);
>> + return bpf_task_work_schedule_signal(task, tw, map__map, callback, aux__prog);
>> }
>
> I thought we decided that _impl() will not be marked as __bpf_kfunc
> and will not be in BTF_ID(func, _impl).
> We can mark it as __weak noinline and it will be in kallsyms.
> That's all we need for the verifier and resolve_btfid, no?
>
> Sorry, it's been a long time. I must have forgotten something.
For the *generated* _impl kfuncs there is no decl tags and the ids are
absent from BTF_ID sets, yes.
However for the "legacy" cases it must be there for backwards
compatibility, as well as relevant verifier checks.
Powered by blists - more mailing lists