Re: [PATCH bpf-next v12 04/13] bpf: support fsession for bpf_session_is_return

[Menglong Dong <menglong.dong@linux.dev>]

On 2026/1/24 12:03, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 13f0a2de33b7..f7baeb8278ca 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> 
> [ ... ]
> 
> > @@ -3341,34 +3349,39 @@ __bpf_kfunc __u64 *bpf_session_cookie(void *ctx)
> >
> >  __bpf_kfunc_end_defs();
> >
> > -BTF_KFUNCS_START(kprobe_multi_kfunc_set_ids)
> > +BTF_KFUNCS_START(session_kfunc_set_ids)
> >  BTF_ID_FLAGS(func, bpf_session_is_return)
> >  BTF_ID_FLAGS(func, bpf_session_cookie)
> > -BTF_KFUNCS_END(kprobe_multi_kfunc_set_ids)
> > +BTF_KFUNCS_END(session_kfunc_set_ids)
> >
> > -static int bpf_kprobe_multi_filter(const struct bpf_prog *prog, u32 kfunc_id)
> > +static int bpf_session_filter(const struct bpf_prog *prog, u32 kfunc_id)
> >  {
> > -	if (!btf_id_set8_contains(&kprobe_multi_kfunc_set_ids, kfunc_id))
> > +	if (!btf_id_set8_contains(&session_kfunc_set_ids, kfunc_id))
> >  		return 0;
> >
> > -	if (!is_kprobe_session(prog) && !is_uprobe_session(prog))
> > +	if (!is_kprobe_session(prog) && !is_uprobe_session(prog) && !is_trace_fsession(prog))
> >  		return -EACCES;
> 
> The filter now allows fsession programs to call both bpf_session_is_return()
> and bpf_session_cookie(). The verifier inline handles bpf_session_is_return()
> for fsession, but what happens when an fsession program calls
> bpf_session_cookie()?
> 
> Looking at bpf_session_cookie() in the same file:
> 
>     __bpf_kfunc __u64 *bpf_session_cookie(void *ctx)
>     {
>         struct bpf_session_run_ctx *session_ctx;
>         session_ctx = container_of(current->bpf_ctx, struct bpf_session_run_ctx, run_ctx);
>         return session_ctx->data;
>     }
> 
> This assumes current->bpf_ctx points to a struct bpf_session_run_ctx, but
> fsession programs use struct bpf_tramp_run_ctx (set up in __bpf_prog_enter*).
> The container_of() will return an incorrect pointer, and session_ctx->data
> will read from the wrong memory location (the saved_run_ctx field of
> bpf_tramp_run_ctx instead of the session cookie).
> 
> Is this intentional to defer bpf_session_cookie() support to a later commit?
> If so, should the filter perhaps only allow bpf_session_is_return() for
> fsession at this point?
> 
> Note: I see that commit b8f4610f8738 ("bpf: support fsession for
> bpf_session_cookie") in the same series adds the verifier inline for
> bpf_session_cookie() with fsession, which would resolve this. However, at
> this commit, calling bpf_session_cookie() from an fsession program would
> produce incorrect results.

As I said before, this patch implement the common part of the fsession.
and we implement the architecture specific code for x86_64 in the later
patch.

> 
> >
> >  	return 0;
> >  }
> 
> [ ... ]
> 
> > +static int __init bpf_trace_kfuncs_init(void)
> >  {
> > -	return register_btf_kfunc_id_set(BPF_PROG_TYPE_KPROBE, &bpf_kprobe_multi_kfunc_set);
> > +	int err = 0;
> > +
> > +	err = err ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_KPROBE, &bpf_session_kfunc_set);
> > +	err = err ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING, &bpf_session_kfunc_set);
> > +
> > +	return err;
> >  }
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
> 
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21308666922
>