On Wed, Apr 8, 2026 at 2:41 AM Ihor Solodrai <[email protected]> wrote: > > On 4/4/26 3:38 AM, Chengkaitao wrote: > > On Sat, Apr 4, 2026 at 12:49 PM Ihor Solodrai <[email protected]> > > wrote: > >> On 4/3/26 10:41 AM, Chengkaitao wrote: > >>> On Tue, Mar 31, 2026 at 1:05 AM Alexei Starovoitov > >>> <[email protected]> wrote: > >>>> > >>>> On Sun, Mar 29, 2026 at 7:05 AM Chengkaitao <[email protected]> wrote: > >>>>> > >>>>> From: Kaitao Cheng <[email protected]> > >>>>> > >>>>> [...] > >>>>> + > >>>>> +/* Kfunc family related to spin_lock. */ > >>>>> +static const enum special_kfunc_type bpf_res_spin_lock_api_kfuncs[] = { > >>>>> + KF_bpf_res_spin_lock, > >>>>> + KF_bpf_res_spin_unlock, > >>>>> + KF_bpf_res_spin_lock_irqsave, > >>>>> + KF_bpf_res_spin_unlock_irqrestore, > >>>>> +}; > > > > ****** Purpose 4 ****** > > > > It pushes us to untangle messy verifier safety cases and make them modular, > > so they can be expressed as parameters to BPF_VERIF_KFUNC_DEF > > Again, I agree with the premise that verifier safety checks could > become more modular where possible. But I think we should first > separate two questions: > > 1. What kfunc properties should be declared centrally? > 2. Where that declaration should live? > > While I'd like to answer (1) with "all of them", I am not convinced > the answer to (2) is .BTF_ids or BTF. A better C side declarative > representation would give us most of the benefit here without making > the BTF tooling more complex. > > Here is how I think we should move forward: > > 1. Your bpf_list_* work is orthogonal to BTF_ID refactoring, so it's > reasonable to first focus on landing it without changes to generic > kfunc handling.
There is no consensus on whether the patch below should exist at all. [PATCH bpf-next v9 1/9] bpf: refactor kfunc checks using table-driven ... Should we drop it entirely, or limit its scope to the is_bpf_* helpers that contain a large number of btf_id == special_kfunc_list[*]-style checks—for example by reverting to v8 or an earlier revision? https://lore.kernel.org/all/[email protected]/ cc: Alexei Starovoitov, Emil Tsalapatis, Leon Hwang, Mykyta Yatsenko, Kumar Kartikeya Dwivedi > 2. I plan to send patches (soon) for resolve_btfids, and then for > BTF_ID macrology to eliminate the enum + array pattern. You are > welcome to join the discussion and review / test the patches. > > 3. After all of the above lands, we can come back to the general > BTF_ID / kfunc handling discussion. If you are interested in > developing this further, I suggest to re-think the approach and come > up with a "single kfunc metadata definition" that doesn't require > significant changes in .BTF_ids section layout. > > A slightly off-topic comment: the usage of `_impl` pattern for kfuncs > should be considered deprecated. Any new kfuncs that work with > verifier-supplied arguments should use KF_IMPLICIT_ARGS mechanism. So > the `bpf_list_add_impl` in your seires should only have one version: > `bpf_list_add` marked with KF_IMPLICIT_ARGS flag. -- Yours, Chengkaitao
