On Mon, Feb 7, 2022 at 9:46 PM Yonghong Song <yhs@xxxxxx> wrote:
>
>
>
> On 2/7/22 2:11 PM, Andrii Nakryiko wrote:
> > On Fri, Feb 4, 2022 at 10:12 AM Dmitrii Dolgov <9erthalion6@xxxxxxxxx> wrote:
> >>
> >> Commit 82e6b1eee6a8 ("bpf: Allow to specify user-provided bpf_cookie for
> >> BPF perf links") introduced the concept of user specified bpf_cookie,
> >> which could be accessed by BPF programs using bpf_get_attach_cookie().
> >> For troubleshooting purposes it is convenient to expose bpf_cookie via
> >> bpftool as well, so there is no need to meddle with the target BPF
> >> program itself.
> >>
> >> $ bpftool link
> >> 1: type 7 prog 5 bpf_cookie 123
> >> pids bootstrap(87)
> >>
> >> Signed-off-by: Dmitrii Dolgov <9erthalion6@xxxxxxxxx>
> >> ---
> >> Changes in v2:
> >> - Display bpf_cookie in bpftool link command instead perf
> >>
> >> Previous discussion: https://lore.kernel.org/bpf/20220127082649.12134-1-9erthalion6@xxxxxxxxx
> >
> >
> > So I think this change is pretty straightforward and I don't mind it,
> > but I'm not clear how this approach will scale to multi-attach kprobe
> > and fentry programs. For those, users will be specifying many bpf
> > cookies, one per each target attach function. At that point we'll have
> > a bunch of cookies sorted by the attach function IP (not necessarily
> > in the original order). I don't think it will be all that useful and
> > interesting to the end user. We won't be storing original function
> > names (too much memory for storing something that most probably won't
> > be ever queried), so restoring original order and original function
> > names will be hard. If we don't think this through, we'll end up with
> > kernel API that works for just one simple use case.
>
> The cookie for multi-attachment is indeed a problem. Some of original
> cookies may not be available any more.
>
> >
> > Can you please describe your use case which motivated this feature in
> > the first place to better understand the importance of this?
> >
> > BTW, bpftool can technically implement this today without kernel
> > changes by fetching such bpf_cookies from the kernel using its pid
> > iterator BPF program. See skeleton/pid_iter.bpf.c for pointers. I
> > wonder if it would make more sense to start with doing this purely on
> > the bpftool side first.
> >
> > As an aside (and probably something more generally useful), it seems
> > like we have a bpf_iter__bpf_map iterator, but we don't have prog and
> > link iterators implemented. Would it be a good idea to add that to the
> > kernel? Yonghong, Alexei, any thoughts?
>
> We already have program iterator. We have discussed link iterators
> for sometime. As more and more usages for links, a link iterator
> should be good to improve performance compared to generic 'task/file'
> iterator.
Agree. We have iters for progs and maps. The iter for links is missing.
