Re: [PATCH bpf-next v2 0/6] Add support to emit verifier warnings

[Leon Hwang <hffilwlqm@gmail.com>]

On 2026/4/8 10:13, Kumar Kartikeya Dwivedi wrote:
> Currently, there are only two ways of communicating information to the user
> when a program is verified, success or failure with a verbose verifier log.
> Some information is meant to be more discretionary, e.g. warning about use of
> kfuncs that are deprecated, and may be removed in future kernel releases.
> 
> An example is shown below.
> 
> $ ./test_progs -t kfunc_implicit_args/test_kfunc_implicit_arg_legacy_impl -v
> ...
> 2: (b7) r3 = 0                        ; R3=0
> 3: (85) call bpf_kfunc_implicit_arg_legacy_impl#114683
> kfunc_implicit_args.c:40 (insn #3) uses deprecated kfunc bpf_kfunc_implicit_arg_legacy_impl(), which will be removed.
> Switch to kfunc bpf_kfunc_implicit_arg_legacy() instead.
> For older kernels, choose the correct kfunc using bpf_ksym_exists().
> 4: R0=scalar()
> 4: (95) exit
> ...
> 
> With verbose logging, the deprecation warnings are printed inline in the
> verifier log. When no log level is chosen, the warning is printed in a
> block, as follows:
> 
> libbpf: prog 'test_kfunc_implicit_arg_legacy_impl': -- BEGIN PROG LOAD WARNINGS --
> kfunc_implicit_args.c:40 (insn #3) uses deprecated kfunc bpf_kfunc_implicit_arg_legacy_impl(), which will be removed.
> Switch to kfunc bpf_kfunc_implicit_arg_legacy() instead.
> For older kernels, choose the correct kfunc using bpf_ksym_exists().
> -- END PROG LOAD WARNINGS --
> 
> The set was tested with and without kernel changes applied, so that we
> could conclude that libbpf feature detection works correctly and
> backwards compatibility is not violated on older kernels. Still, it
> would be helpful if other reviewers could recheck all assumptions and
> make sure I didn't miss any corner case.
> 
> One case I need more opinions on: log_buf.c passes log_buf with
> log_level=0 and expects it to be empty, with newer libbpf that won't be
> true on older kernels anymore. I don't think this is something that
> needs to be addressed, but explicitly noting it here since I saw that
> test fail when testing new libbpf on older kernels. The kernel will now
> populate such log_buf will "processed N insns ..." log since on failure
> libbpf will retry with log_level=1, so unless applications are relying
> on log_buf to be empty for correctness it should be ok.
> 

Since I'm going to add common attributes [1] support for BPF syscall,
how about reporting the warnings via the common attributes? Even though,
the original intent of common attributes support for BPF_LOAD was to
report the verifier log too.

[1] https://lore.kernel.org/bpf/20260216150445.68278-1-leon.hwang@linux.dev/

Thanks,
Leon