Re: [PATCH bpf-next 3/6] bpf: fetch the vmlinux BTF where kernel types enter a program

[Jiri Olsa]

On Wed, Sep 23, 2026 at 06:28:43AM +0000, bot+bpf-ci@xxxxxxxxxx wrote:

SNIP

> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 195f78db9bda..c022b2877f0b 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -1015,7 +1015,8 @@ static int bpf_btf_printf_prepare(struct btf_ptr *ptr, u32 btf_ptr_size,
> >  	if (btf_ptr_size != sizeof(struct btf_ptr))
> >  		return -EINVAL;
> >
> > -	*btf = bpf_get_btf_vmlinux();
> > +	/* Called from a running program: only use the BTF if it is parsed. */
> > +	*btf = bpf_peek_btf_vmlinux();
> >
> >  	if (IS_ERR_OR_NULL(*btf))
> >  		return IS_ERR(*btf) ? PTR_ERR(*btf) : -EINVAL;
> 
> Swapping bpf_get_btf_vmlinux() for bpf_peek_btf_vmlinux() is correct as a
> sleeping-in-program-context fix, but does anything in this commit arrange
> for the BTF to have been parsed by the time bpf_snprintf_btf() or
> bpf_seq_printf_btf() run?
> 
> The compensating verifier-time fetch in check_helper_call() is gated on
> helper_uses_vmlinux_btf(), which only matches base_type(ret_type) ==
> RET_PTR_TO_BTF_ID or base_type(arg_type[i]) == ARG_PTR_TO_BTF_ID.
> 
> bpf_snprintf_btf_proto and bpf_seq_printf_btf_proto contain neither: their
> arguments are ARG_PTR_TO_MEM / ARG_CONST_SIZE / ARG_ANYTHING and the return
> is RET_INTEGER, because the BTF type id travels inside the struct btf_ptr
> the program passes by value rather than in a register type.
> 
> So helper_uses_vmlinux_btf() returns false for exactly the two helpers
> whose runtime fetch was just weakened.
> 
> On a CONFIG_DEBUG_INFO_BTF=m kernel where the BTF is present but not yet
> parsed, bpf_peek_btf_vmlinux() returns NULL and the helper returns -EINVAL.
> A working bpf_snprintf_btf() or bpf_seq_printf_btf() call silently starts
> failing, depending on whether unrelated activity already triggered the
> parse.
> 
> The changelog frames this as behaving "as they do on a kernel without BTF",
> but the BTF is available, just unparsed, and the previous code would have
> produced correct output.
> 
> Should the fix be at verify time - teaching helper_uses_vmlinux_btf(), or
> check_bpf_snprintf_call(), or the *_btf protos, to force the fetch? The
> forward range 90fe51b6b36a..2f5aab95d2b8 contains no code change for this.

seems valid to me, could we just check for these two print helpers in
helper_uses_vmlinux_btf ?

jirka