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
