Re: [PATCH bpf-next v9 05/11] bpf: support fsession for bpf_session_cookie

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

On 2026/1/14 09:22 Andrii Nakryiko <andrii.nakryiko@gmail.com> write:
> On Sat, Jan 10, 2026 at 6:12 AM Menglong Dong <menglong8.dong@gmail.com> wrote:
> >
> > Implement session cookie for fsession. In order to limit the stack usage,
> > we make 4 as the maximum of the cookie count.
> 
> This 4 is so random, tbh. Do we need to artificially limit it? Even if
> all BPF_MAX_TRAMP_LINKS = 38 where using session cookies, it would be
> 304 bytes. Not insignificant, but also not world-ending and IMO so
> unlikely that I wouldn't add extra limits at all.

I'll remove the limitation in the next version.

> 
> >
> > The offset of the current cookie is stored in the
> > "(ctx[-1] >> BPF_TRAMP_M_COOKIE) & 0xFF". Therefore, we can get the
> > session cookie with ctx[-offset].
> 
> 
> ctx here is assumed u64 *, right? So offset is in 8-byte units? Can
> you clarify please?

Yes, ctx is u64 * and the offset is 8-byte units. I'll describe it
here.

> 
> >
> > The stack will look like this:
> >
> >   return value  -> 8 bytes
> >   argN          -> 8 bytes
> >   ...
[...]
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 2640ec2157e1..a416050e0dd2 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -1231,6 +1231,7 @@ enum {
> >
> >  #define BPF_TRAMP_M_NR_ARGS    0
> >  #define BPF_TRAMP_M_IS_RETURN  8
> > +#define BPF_TRAMP_M_COOKIE     9
> 
> this is not wrong, but certainly weird. Why not make IS_RETURN to be
> the upper bit (63) and keep cookie as a proper second byte?

OK, I think it make sense, which can make the usage of the
func_meta more clear. So for the flag bit, we put it at the
high significant bit. And for the offset filed, we put it at the
low significant bit.

> 
> 
> (also I think all these should drop _M and have _SHIFT suffix)
> 

Glad to hear some advice about the name. I'll use it.

> 
> >