Re: [PATCH bpf-next 3/6] bpf: Add link_info support for uprobe multi link

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Oct 27, 2023 at 03:59:33PM +0200, Jiri Olsa wrote:
> On Thu, Oct 26, 2023 at 07:57:27PM +0800, Yafang Shao wrote:
> > On Thu, Oct 26, 2023 at 4:24 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > >
> > > Adding support to get uprobe_link details through bpf_link_info
> > > interface.
> > >
> > > Adding new struct uprobe_multi to struct bpf_link_info to carry
> > > the uprobe_multi link details.
> > >
> > > The uprobe_multi.count is passed from user space to denote size
> > > of array fields (offsets/ref_ctr_offsets/cookies). The actual
> > > array size is stored back to uprobe_multi.count (allowing user
> > > to find out the actual array size) and array fields are populated
> > > up to the user passed size.
> > >
> > > All the non-array fields (path/count/flags/pid) are always set.
> > >
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > > ---
> > >  include/uapi/linux/bpf.h       | 10 +++++
> > >  kernel/trace/bpf_trace.c       | 68 ++++++++++++++++++++++++++++++++++
> > >  tools/include/uapi/linux/bpf.h | 10 +++++
> > >  3 files changed, 88 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> > > index 0f6cdf52b1da..960cf2914d63 100644
> > > --- a/include/uapi/linux/bpf.h
> > > +++ b/include/uapi/linux/bpf.h
> > > @@ -6556,6 +6556,16 @@ struct bpf_link_info {
> > >                         __u32 flags;
> > >                         __u64 missed;
> > >                 } kprobe_multi;
> > > +               struct {
> > > +                       __aligned_u64 path;
> > > +                       __aligned_u64 offsets;
> > > +                       __aligned_u64 ref_ctr_offsets;
> > > +                       __aligned_u64 cookies;
> > 
> > The bpf cookie for the perf_event link is exposed through
> > 'pid_iter.bpf.c,' while the cookies for the tracing link and
> > kprobe_multi link are not exposed at all. This inconsistency can be
> > confusing. I believe it would be better to include all of them in the
> > link_info. The reason is that 'pid_iter' depends on the task holding
> > the links, which may not exist. However, I think we handle this in a
> > separate patchset. What do you think?
> 
> right, I think we should add cookies for both kprobe_multi
> and tracing link, I'll add that in new version

actually.. ;-) it's 5 extra patches already even without bpftool
changes, so I'll send it separately after this one gets merged

jirka