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

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Nov 01, 2023 at 03:21:36PM -0700, Andrii Nakryiko wrote:

SNIP

> > +               struct {
> > +                       __aligned_u64 path;
> > +                       __aligned_u64 offsets;
> > +                       __aligned_u64 ref_ctr_offsets;
> > +                       __aligned_u64 cookies;
> > +                       __u32 path_max; /* in/out: uprobe_multi path size */
> 
> people already called out that path_size makes for a better name, I agree
> 
> > +                       __u32 count;    /* in/out: uprobe_multi offsets/ref_ctr_offsets/cookies count */
> 
> otherwise we'd have to call this count_max :)

path_size is good ;-)


> 
> > +                       __u32 flags;
> > +                       __u32 pid;
> > +               } uprobe_multi;
> >                 struct {
> >                         __u32 type; /* enum bpf_perf_event_type */
> >                         __u32 :32;
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 843b3846d3f8..9f8ad19a1a93 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -3042,6 +3042,7 @@ struct bpf_uprobe_multi_link {
> >         u32 cnt;
> >         struct bpf_uprobe *uprobes;
> >         struct task_struct *task;
> > +       u32 flags;
> >  };
> >
> >  struct bpf_uprobe_multi_run_ctx {
> > @@ -3081,9 +3082,75 @@ static void bpf_uprobe_multi_link_dealloc(struct bpf_link *link)
> >         kfree(umulti_link);
> >  }
> >
> > +static int bpf_uprobe_multi_link_fill_link_info(const struct bpf_link *link,
> > +                                               struct bpf_link_info *info)
> > +{
> > +       u64 __user *uref_ctr_offsets = u64_to_user_ptr(info->uprobe_multi.ref_ctr_offsets);
> > +       u64 __user *ucookies = u64_to_user_ptr(info->uprobe_multi.cookies);
> > +       u64 __user *uoffsets = u64_to_user_ptr(info->uprobe_multi.offsets);
> > +       u64 __user *upath = u64_to_user_ptr(info->uprobe_multi.path);
> > +       u32 upath_max = info->uprobe_multi.path_max;
> > +       struct bpf_uprobe_multi_link *umulti_link;
> > +       u32 ucount = info->uprobe_multi.count;
> > +       int err = 0, i;
> > +       char *p, *buf;
> > +       long left;
> > +
> > +       if (!upath ^ !upath_max)
> > +               return -EINVAL;
> > +
> > +       if (!uoffsets ^ !ucount)
> > +               return -EINVAL;
> > +
> > +       umulti_link = container_of(link, struct bpf_uprobe_multi_link, link);
> > +       info->uprobe_multi.count = umulti_link->cnt;
> > +       info->uprobe_multi.flags = umulti_link->flags;
> > +       info->uprobe_multi.pid = umulti_link->task ?
> > +                                task_pid_nr(umulti_link->task) : (u32) -1;
> 
> on attach we do
> 
> task = get_pid_task(find_vpid(pid), PIDTYPE_PID);
> 
> So on attachment we take pid in user's namespace, is that right? It's
> kind of asymmetrical that we return the global PID back? Should we try
> to convert PID to user's namespace instead?

you're right, I think we should use this:

  task_pid_nr_ns(umulti_link->task, task_active_pid_ns(current))

> 
> > +
> > +       if (upath) {
> > +               if (upath_max > PATH_MAX)
> > +                       return -E2BIG;
> 
> no need to fail here, as pointed out elsewhere
> 
> > +               buf = kmalloc(upath_max, GFP_KERNEL);
> 
> here we can allocate min(PATH_MAX, upath_max)

yes, will do that

> 
> > +               if (!buf)
> > +                       return -ENOMEM;
> > +               p = d_path(&umulti_link->path, buf, upath_max);
> > +               if (IS_ERR(p)) {
> > +                       kfree(buf);
> > +                       return -ENOSPC;
> > +               }
> > +               left = copy_to_user(upath, p, buf + upath_max - p);
> > +               kfree(buf);
> > +               if (left)
> > +                       return -EFAULT;
> > +       }
> > +
> > +       if (!uoffsets)
> > +               return 0;
> 
> it would be good to still return actual counts for out parameters, no?

hm, we do that few lines above with:

        info->uprobe_multi.count = umulti_link->cnt;

if that's what you mean

thanks,
jirka