linux-kernel - Re: [PATCH bpf-next v1 08/10] bpf: Add bpf_task_work_schedule_* kfuncs with KF_IMPLICIT

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f0e63b55-65c3-4367-b3da-275df18147a1@linux.dev>
Date: Fri, 9 Jan 2026 13:56:26 -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 1:49 PM, Alexei Starovoitov wrote:
> On Fri, Jan 9, 2026 at 1:39 PM Ihor Solodrai <ihor.solodrai@...ux.dev> wrote:
>>
>> On 1/9/26 12:47 PM, Alexei Starovoitov wrote:
>>> On Fri, Jan 9, 2026 at 12:02 PM Ihor Solodrai <ihor.solodrai@...ux.dev> wrote:
>>>>
>>>> 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.
>>>
>>> I see.
>>> I feel bpf_task_work_schedule_resume() is ok to break, since it's so new.
>>> We can remove bpf_task_work_schedule_[resume|singal]_impl()
>>> to avoid carrying forward forever.
>>>
>>> bpf_stream_vprintk_impl() is not that clear. I would remove it too.
>>
>> That leaves only bpf_wq_set_callback_impl(). Can we break that too?
> 
> Sounds like Benjamin is ok removing it.
> So I think we can indeed remove them all.
> 
>> Then there won't be legacy cases at all. It was introduced in v6.16
>> along the with __prog suffix [1][2].
>>
>> If we go this route, we could clean up __prog support/docs too.
>>
>> I think it's worth it to make an "all or nothing" decision here:
>> either break all 4 existing kfuncs, or backwards-support all of them.
> 
> I don't see why "all or nothing" is a good thing.
> It won't be "all" anyway.
> We have bpf_rbtree_add_impl(), bpf_list_push_front_impl(), etc.
> And those we cannot remove. sched-ext is using them.
> Another few categories are bpf_obj_new_impl(), bpf_obj_drop_impl().
> There are not __prog type, but conceptually the same thing and
> KF_IMPLICIT_ARGS should support them too eventually.

I was thinking we could remove/simplify code relevant to backwards
compat of existing _impl kfuncs. But you're right, if we start using
implicit args for other types/kfuncs, the "legacy" case still has to
work.

Ok, in the next revision I'll remove all the __prog users, but leave
the "legacy" case support in place for future use.

> 
> 
>> git tag --contains bc049387b41f | grep -v rc
>> v6.16
>> v6.17
>> v6.18
>>
>> [1] https://lore.kernel.org/all/20250513142812.1021591-1-memxor@gmail.com/
>> [2] https://lore.kernel.org/all/20240420-bpf_wq-v2-13-6c986a5a741f@kernel.org/
>>
>>