Re: [PATCH RFCv2 bpf-next 2/4] bpf: Add bpf_kprobe_multi_is_return kfunc

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Mar 01, 2024 at 10:01:16AM -0800, Andrii Nakryiko wrote:

sNIP

> > > > +__bpf_kfunc bool bpf_kprobe_multi_is_return(void)
> > >
> > > and for uprobes we'll have bpf_uprobe_multi_is_return?...
> >
> > yes, but now I'm thinking maybe we could also have 'session' api and
> > have single 'bpf_session_is_return' because both kprobe and uprobe
> > are KPROBE program type.. and align it together with other session
> > kfuncs:
> >
> >   bpf_session_is_return
> >   bpf_session_set_cookie
> >   bpf_session_get_cookie
> >
> 
> We can do that. But I was thinking more of a
> 
> u64 *bpf_session_cookie()
> 
> which would return a read/write pointer that BPF program can
> manipulate. Instead of doing two calls (get_cookie + set_cookie), it
> would be one call. Is there any benefit to having separate set/get
> cookie calls?

ok, that would be easier, will check on that

> 
> > >
> > > BTW, have you tried implementing a "session cookie" idea?
> >
> > yep, with a little fix [0] it's working on top of Masami's 'fprobe over fgraph'
> > changes, you can check last 2 patches in [1] .. I did not do this on top of the
> > current fprobe/rethook kernel code, because it seems it's about to go away
> 
> do you know what is the timeline for fprobe over fgraph work to be finished?

good question ;-) Masami, any idea?

fwiw there's new version needed for [1] fix

[1] https://lore.kernel.org/bpf/ZdyKaRiI-PnG80Q0@krava/

> 
> >
> > I still need to implement that on top of uprobes and I will send rfc, so we can
> > see all of it and discuss the interface
> >
> 
> great, yeah, I think the session cookie idea should go in at the same
> time, if possible, so that we can assume it is supported for new
> [ku]probe.wrapper programs.

makes sense, even though with new kfuncs detection stuff,
it will be easy to find out

jirka