On 4/9/26 7:53 PM, Chengkaitao wrote: > On Wed, Apr 8, 2026 at 2:41 AM Ihor Solodrai <[email protected]> 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/[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. >
