> On Mon, Feb 07, 2022 at 02:11:11PM -0800, 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.
>
> Can you please describe your use case which motivated this feature in
> the first place to better understand the importance of this?
The use case is pretty theoretical at the moment, I'm trying to
understand how to get more visibility about bpf_cookie usage. Let me try
to do the same only in bpftool, while pondering if multi-attach programs
case could be somehow meaningfully addressed as well.
