Re: [PATCH bpf-next v10 07/12] bpf,x86: add fsession support for x86_64

[Andrii Nakryiko]

On Wed, Jan 21, 2026 at 4:06 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Thu, Jan 15, 2026 at 3:24 AM Menglong Dong <menglong8.dong@xxxxxxxxx> wrote:
> >
> > Add BPF_TRACE_FSESSION supporting to x86_64, including:
> >
> > 1. clear the return value in the stack before fentry to make the fentry
> >    of the fsession can only get 0 with bpf_get_func_ret().
> >
> > 2. clear all the session cookies' value in the stack.
> >
> > 2. store the index of the cookie to ctx[-1] before the calling to fsession
> >
> > 3. store the "is_return" flag to ctx[-1] before the calling to fexit of
> >    the fsession.
> >
> > Signed-off-by: Menglong Dong <dongml2@xxxxxxxxxxxxxxx>
> > Co-developed-by: Leon Hwang <leon.hwang@xxxxxxxxx>
> > Signed-off-by: Leon Hwang <leon.hwang@xxxxxxxxx>
> > ---
> > v10:
> > - use "|" for func_meta instead of "+"
> > - pass the "func_meta_off" to invoke_bpf() explicitly, instead of
> >   computing it with "stack_size + 8"
> > - pass the "cookie_off" to invoke_bpf() instead of computing the current
> >   cookie index with "func_meta"
> >
> > v5:
> > - add the variable "func_meta"
> > - define cookie_off in a new line
> >
> > v4:
> > - some adjustment to the 1st patch, such as we get the fsession prog from
> >   fentry and fexit hlist
> > - remove the supporting of skipping fexit with fentry return non-zero
> >
> > v2:
> > - add session cookie support
> > - add the session stuff after return value, instead of before nr_args
> > ---
> >  arch/x86/net/bpf_jit_comp.c | 52 ++++++++++++++++++++++++++++---------
> >  1 file changed, 40 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > index 2f31331955b5..16720f2be16c 100644
> > --- a/arch/x86/net/bpf_jit_comp.c
> > +++ b/arch/x86/net/bpf_jit_comp.c
> > @@ -3094,13 +3094,19 @@ static int emit_cond_near_jump(u8 **pprog, void *func, void *ip, u8 jmp_cond)
> >
> >  static int invoke_bpf(const struct btf_func_model *m, u8 **pprog,
> >                       struct bpf_tramp_links *tl, int stack_size,
> > -                     int run_ctx_off, bool save_ret,
> > -                     void *image, void *rw_image)
> > +                     int run_ctx_off, int func_meta_off, bool save_ret,
> > +                     void *image, void *rw_image, u64 func_meta,
> > +                     int cookie_off)
> >  {
> > -       int i;
> > +       int i, cur_cookie = (cookie_off - stack_size) / 8;
>
> not sure why you went with passing cookie_off and then calculating,
> effectively, cookie count out of that?... why not pass cookie count
> directly then? it's minor, but just seems like a weird choice here,
> tbh
>

consider also just calculating cookie count out from bpf_tramp_links?
would that work? Then "func_meta" would really be just nr_args (and
I'd call it that) and bool for whether this is entry or exit
invokation (for IS_RETURN bit, and maybe we'll need this distinction
somewhere else in the future), and then invoke_bpf() will construct
func_meta from scratch.

It's relatively minor thing, but as I mentioned before, it's this
hybrid approach of partially opaque (from invoke_bpf's POV) func_meta
which we also adjust or fill out (for cookie index) is a bit of a sign
that this is not a proper interface.

>
>
> >         u8 *prog = *pprog;
> >
> >         for (i = 0; i < tl->nr_links; i++) {
> > +               if (tl->links[i]->link.prog->call_session_cookie) {
> > +                       emit_store_stack_imm64(&prog, BPF_REG_0, -func_meta_off,
> > +                                              func_meta | (cur_cookie << BPF_TRAMP_SHIFT_COOKIE));
> > +                       cur_cookie--;
> > +               }
> >                 if (invoke_bpf_prog(m, &prog, tl->links[i], stack_size,
> >                                     run_ctx_off, save_ret, image, rw_image))
> >                         return -EINVAL;
>
> [...]