On Sat, Mar 12, 2022 at 2:59 PM Quentin Monnet <quentin@xxxxxxxxxxxxx> wrote:
>
> On Fri, 11 Mar 2022 at 22:25, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Wed, Mar 9, 2022 at 8:33 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.
> > >
> > > Implemented using the pid iterator BPF program to actually fetch
> > > bpf_cookies, which allows constraining code changes only to bpftool.
> > >
> > > $ bpftool link
> > > 1: type 7 prog 5
> > > bpf_cookie 123
> > > pids bootstrap(81)
> > >
> > > Signed-off-by: Dmitrii Dolgov <9erthalion6@xxxxxxxxx>
> > > Acked-by: Yonghong Song <yhs@xxxxxx>
> > > ---
> >
> > Quentin, any opinion on this feature? The implementation seems
> > straightforward enough. We'll need to not forget to expand the support
> > to other types that support bpf_cookies (and multi-attach kprobes and
> > fentries will be problematic, potentially), but this might be useful
> > for debugging purposes.
>
> No strong opinion. I'm generally in favour of adding more useful info
> to bpftool's output; I've not found myself in need for the bpf_cookie
> so far, but if it's helpful for debugging, then it makes sense to me
> that bpftool be the tool to provide the info. The change looks clean
Can I get your ack for this change, then?
> indeed. Agreed also that this will require us to think of updating
> bpftool when new types gain support for the cookies. What would be the
> problem with multi-attach, the kprobes/fentries would have several
> cookies?
Yes, multi-attach links will have one cookie for each attach target,
so there will be, in general, a multitude of cookie values.
>
> Quentin
