Re: [PATCH bpf-next v9 1/9] bpf: refactor kfunc checks using table-driven approach in verifier

[Ihor Solodrai]

On 4/9/26 7:53 PM, Chengkaitao wrote:
> On Wed, Apr 8, 2026 at 2:41 AM Ihor Solodrai <ihor.solodrai@xxxxxxxxx> wrote:
>>
>> On 4/4/26 3:38 AM, Chengkaitao wrote:
>>>
>>> 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 ...

Hi Kaitao,

I think this refactoring patch should be dropped from the series.
For now use the established pattern with special_kfunc_list, and don't
introduce new _impl kfuncs.

> 
> 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?

I don't think "reverting to v8" will work. Since you've sent v9
significant changes to the verifier.c have been landed, so you have
some rebase work to do anyways.  I suggest you minimize unnecessary
refactoring in this series, and focus on bpf_list_* api extension.

pw-bot: cr

Thanks, and apologies for slow reply.


> https://lore.kernel.org/all/20260316112843.78657-2-pilgrimtao@xxxxxxxxx/
> 
> 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.
>