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
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?
Quentin
