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.
include/uapi/linux/bpf.h | 3 +++
kernel/bpf/syscall.c | 13 +++++++++++++
tools/bpf/bpftool/link.c | 2 ++
tools/include/uapi/linux/bpf.h | 3 +++
4 files changed, 21 insertions(+)
[...]
