All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
@ 2022-03-09 16:31 Dmitrii Dolgov
  2022-03-11 22:24 ` Andrii Nakryiko
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Dmitrii Dolgov @ 2022-03-09 16:31 UTC (permalink / raw)
  To: bpf, ast, daniel, andrii, quentin, yhs; +Cc: Dmitrii Dolgov

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@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
---
Changes in v6:
    - Remove unnecessary initialization of fields in pid_iter_entry
    - Changing bpf_cookie_set to has_bpf_cookie
    - Small code cleanup (casting bpf_cookie when needed, removing
      __always_inline, etc.)

Changes in v5:
    - Remove unneeded cookie assigns

Changes in v4:
    - Fetch cookies only for bpf_perf_link
    - Signal about bpf_cookie via the flag, instead of deducing it from
      the object and link type
    - Reset pid_iter_entry to avoid invalid indirect read from stack

Changes in v3:
    - Use pid iterator to fetch bpf_cookie

Changes in v2:
    - Display bpf_cookie in bpftool link command instead perf

Previous discussion: https://lore.kernel.org/bpf/20220225152802.20957-1-9erthalion6@gmail.com/

 tools/bpf/bpftool/main.h                  |  2 ++
 tools/bpf/bpftool/pids.c                  |  8 ++++++++
 tools/bpf/bpftool/skeleton/pid_iter.bpf.c | 22 ++++++++++++++++++++++
 tools/bpf/bpftool/skeleton/pid_iter.h     |  2 ++
 4 files changed, 34 insertions(+)

diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
index 0c3840596b5a..3574bef7d4ce 100644
--- a/tools/bpf/bpftool/main.h
+++ b/tools/bpf/bpftool/main.h
@@ -114,6 +114,8 @@ struct obj_ref {
 struct obj_refs {
 	int ref_cnt;
 	struct obj_ref *refs;
+	bool has_bpf_cookie;
+	__u64 bpf_cookie;
 };
 
 struct btf;
diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
index 7c384d10e95f..bb6c969a114a 100644
--- a/tools/bpf/bpftool/pids.c
+++ b/tools/bpf/bpftool/pids.c
@@ -78,6 +78,8 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
 	ref->pid = e->pid;
 	memcpy(ref->comm, e->comm, sizeof(ref->comm));
 	refs->ref_cnt = 1;
+	refs->has_bpf_cookie = e->has_bpf_cookie;
+	refs->bpf_cookie = e->bpf_cookie;
 
 	err = hashmap__append(map, u32_as_hash_field(e->id), refs);
 	if (err)
@@ -205,6 +207,9 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
 		if (refs->ref_cnt == 0)
 			break;
 
+		if (refs->has_bpf_cookie)
+			jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
+
 		jsonw_name(json_writer, "pids");
 		jsonw_start_array(json_writer);
 		for (i = 0; i < refs->ref_cnt; i++) {
@@ -234,6 +239,9 @@ void emit_obj_refs_plain(struct hashmap *map, __u32 id, const char *prefix)
 		if (refs->ref_cnt == 0)
 			break;
 
+		if (refs->has_bpf_cookie)
+			printf("\n\tbpf_cookie %llu", (unsigned long long) refs->bpf_cookie);
+
 		printf("%s", prefix);
 		for (i = 0; i < refs->ref_cnt; i++) {
 			struct obj_ref *ref = &refs->refs[i];
diff --git a/tools/bpf/bpftool/skeleton/pid_iter.bpf.c b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
index f70702fcb224..eb05ea53afb1 100644
--- a/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
+++ b/tools/bpf/bpftool/skeleton/pid_iter.bpf.c
@@ -38,6 +38,17 @@ static __always_inline __u32 get_obj_id(void *ent, enum bpf_obj_type type)
 	}
 }
 
+/* could be used only with BPF_LINK_TYPE_PERF_EVENT links */
+static __u64 get_bpf_cookie(struct bpf_link *link)
+{
+	struct bpf_perf_link *perf_link;
+	struct perf_event *event;
+
+	perf_link = container_of(link, struct bpf_perf_link, link);
+	event = BPF_CORE_READ(perf_link, perf_file, private_data);
+	return BPF_CORE_READ(event, bpf_cookie);
+}
+
 SEC("iter/task_file")
 int iter(struct bpf_iter__task_file *ctx)
 {
@@ -69,8 +80,19 @@ int iter(struct bpf_iter__task_file *ctx)
 	if (file->f_op != fops)
 		return 0;
 
+	__builtin_memset(&e, 0, sizeof(e));
 	e.pid = task->tgid;
 	e.id = get_obj_id(file->private_data, obj_type);
+
+	if (obj_type == BPF_OBJ_LINK) {
+		struct bpf_link *link = (struct bpf_link *) file->private_data;
+
+		if (BPF_CORE_READ(link, type) == BPF_LINK_TYPE_PERF_EVENT) {
+			e.has_bpf_cookie = true;
+			e.bpf_cookie = get_bpf_cookie(link);
+		}
+	}
+
 	bpf_probe_read_kernel_str(&e.comm, sizeof(e.comm),
 				  task->group_leader->comm);
 	bpf_seq_write(ctx->meta->seq, &e, sizeof(e));
diff --git a/tools/bpf/bpftool/skeleton/pid_iter.h b/tools/bpf/bpftool/skeleton/pid_iter.h
index 5692cf257adb..bbb570d4cca6 100644
--- a/tools/bpf/bpftool/skeleton/pid_iter.h
+++ b/tools/bpf/bpftool/skeleton/pid_iter.h
@@ -6,6 +6,8 @@
 struct pid_iter_entry {
 	__u32 id;
 	int pid;
+	__u64 bpf_cookie;
+	bool has_bpf_cookie;
 	char comm[16];
 };
 
-- 
2.32.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-09 16:31 [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output Dmitrii Dolgov
@ 2022-03-11 22:24 ` Andrii Nakryiko
  2022-03-12 22:59   ` Quentin Monnet
  2022-03-15 22:10 ` patchwork-bot+netdevbpf
  2022-03-26  1:38 ` Quentin Monnet
  2 siblings, 1 reply; 11+ messages in thread
From: Andrii Nakryiko @ 2022-03-11 22:24 UTC (permalink / raw)
  To: Dmitrii Dolgov
  Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Quentin Monnet, Yonghong Song

On Wed, Mar 9, 2022 at 8:33 AM Dmitrii Dolgov <9erthalion6@gmail.com> 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@gmail.com>
> Acked-by: Yonghong Song <yhs@fb.com>
> ---

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.

> Changes in v6:
>     - Remove unnecessary initialization of fields in pid_iter_entry
>     - Changing bpf_cookie_set to has_bpf_cookie
>     - Small code cleanup (casting bpf_cookie when needed, removing
>       __always_inline, etc.)
>
> Changes in v5:
>     - Remove unneeded cookie assigns
>
> Changes in v4:
>     - Fetch cookies only for bpf_perf_link
>     - Signal about bpf_cookie via the flag, instead of deducing it from
>       the object and link type
>     - Reset pid_iter_entry to avoid invalid indirect read from stack
>
> Changes in v3:
>     - Use pid iterator to fetch bpf_cookie
>
> Changes in v2:
>     - Display bpf_cookie in bpftool link command instead perf
>
> Previous discussion: https://lore.kernel.org/bpf/20220225152802.20957-1-9erthalion6@gmail.com/
>
>  tools/bpf/bpftool/main.h                  |  2 ++
>  tools/bpf/bpftool/pids.c                  |  8 ++++++++
>  tools/bpf/bpftool/skeleton/pid_iter.bpf.c | 22 ++++++++++++++++++++++
>  tools/bpf/bpftool/skeleton/pid_iter.h     |  2 ++
>  4 files changed, 34 insertions(+)
>

[...]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-11 22:24 ` Andrii Nakryiko
@ 2022-03-12 22:59   ` Quentin Monnet
  2022-03-15 18:33     ` Andrii Nakryiko
  0 siblings, 1 reply; 11+ messages in thread
From: Quentin Monnet @ 2022-03-12 22:59 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: Dmitrii Dolgov, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Yonghong Song

On Fri, 11 Mar 2022 at 22:25, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> On Wed, Mar 9, 2022 at 8:33 AM Dmitrii Dolgov <9erthalion6@gmail.com> 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@gmail.com>
> > Acked-by: Yonghong Song <yhs@fb.com>
> > ---
>
> 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-12 22:59   ` Quentin Monnet
@ 2022-03-15 18:33     ` Andrii Nakryiko
  2022-03-15 21:01       ` Quentin Monnet
  0 siblings, 1 reply; 11+ messages in thread
From: Andrii Nakryiko @ 2022-03-15 18:33 UTC (permalink / raw)
  To: Quentin Monnet
  Cc: Dmitrii Dolgov, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Yonghong Song

On Sat, Mar 12, 2022 at 2:59 PM Quentin Monnet <quentin@isovalent.com> wrote:
>
> On Fri, 11 Mar 2022 at 22:25, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> >
> > On Wed, Mar 9, 2022 at 8:33 AM Dmitrii Dolgov <9erthalion6@gmail.com> 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@gmail.com>
> > > Acked-by: Yonghong Song <yhs@fb.com>
> > > ---
> >
> > 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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-15 18:33     ` Andrii Nakryiko
@ 2022-03-15 21:01       ` Quentin Monnet
  0 siblings, 0 replies; 11+ messages in thread
From: Quentin Monnet @ 2022-03-15 21:01 UTC (permalink / raw)
  To: Andrii Nakryiko
  Cc: Dmitrii Dolgov, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Yonghong Song



Le 15 mars 2022 18:33:02 GMT+00:00, Andrii Nakryiko <andrii.nakryiko@gmail.com> a écrit :
>On Sat, Mar 12, 2022 at 2:59 PM Quentin Monnet <quentin@isovalent.com> wrote:
>>
>> On Fri, 11 Mar 2022 at 22:25, Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>> >
>> > On Wed, Mar 9, 2022 at 8:33 AM Dmitrii Dolgov <9erthalion6@gmail.com> 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@gmail.com>
>> > > Acked-by: Yonghong Song <yhs@fb.com>
>> > > ---
>> >
>> > 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?

Acked-by: Quentin Monnet <quentin@isovalent.com>

>
>> 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.

OK thank you
Quant in

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-09 16:31 [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output Dmitrii Dolgov
  2022-03-11 22:24 ` Andrii Nakryiko
@ 2022-03-15 22:10 ` patchwork-bot+netdevbpf
  2022-03-26  1:38 ` Quentin Monnet
  2 siblings, 0 replies; 11+ messages in thread
From: patchwork-bot+netdevbpf @ 2022-03-15 22:10 UTC (permalink / raw)
  To: Dmitrii Dolgov; +Cc: bpf, ast, daniel, andrii, quentin, yhs

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@kernel.org>:

On Wed,  9 Mar 2022 17:31:12 +0100 you 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.
> 
> [...]

Here is the summary with links:
  - [bpf-next,v6] bpftool: Add bpf_cookie to link output
    https://git.kernel.org/bpf/bpf-next/c/cbdaf71f7e65

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-09 16:31 [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output Dmitrii Dolgov
  2022-03-11 22:24 ` Andrii Nakryiko
  2022-03-15 22:10 ` patchwork-bot+netdevbpf
@ 2022-03-26  1:38 ` Quentin Monnet
  2022-03-26  9:08   ` Dmitry Dolgov
  2 siblings, 1 reply; 11+ messages in thread
From: Quentin Monnet @ 2022-03-26  1:38 UTC (permalink / raw)
  To: Dmitrii Dolgov, bpf, ast, daniel, andrii, yhs

2022-03-09 17:31 UTC+0100 ~ Dmitrii Dolgov <9erthalion6@gmail.com>
> 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@gmail.com>
> Acked-by: Yonghong Song <yhs@fb.com>
> ---
> Changes in v6:
>     - Remove unnecessary initialization of fields in pid_iter_entry
>     - Changing bpf_cookie_set to has_bpf_cookie
>     - Small code cleanup (casting bpf_cookie when needed, removing
>       __always_inline, etc.)
> 
> Changes in v5:
>     - Remove unneeded cookie assigns
> 
> Changes in v4:
>     - Fetch cookies only for bpf_perf_link
>     - Signal about bpf_cookie via the flag, instead of deducing it from
>       the object and link type
>     - Reset pid_iter_entry to avoid invalid indirect read from stack
> 
> Changes in v3:
>     - Use pid iterator to fetch bpf_cookie
> 
> Changes in v2:
>     - Display bpf_cookie in bpftool link command instead perf
> 
> Previous discussion: https://lore.kernel.org/bpf/20220225152802.20957-1-9erthalion6@gmail.com/
> 
>  tools/bpf/bpftool/main.h                  |  2 ++
>  tools/bpf/bpftool/pids.c                  |  8 ++++++++
>  tools/bpf/bpftool/skeleton/pid_iter.bpf.c | 22 ++++++++++++++++++++++
>  tools/bpf/bpftool/skeleton/pid_iter.h     |  2 ++
>  4 files changed, 34 insertions(+)
> 
> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
> index 0c3840596b5a..3574bef7d4ce 100644
> --- a/tools/bpf/bpftool/main.h
> +++ b/tools/bpf/bpftool/main.h
> @@ -114,6 +114,8 @@ struct obj_ref {
>  struct obj_refs {
>  	int ref_cnt;
>  	struct obj_ref *refs;
> +	bool has_bpf_cookie;
> +	__u64 bpf_cookie;
>  };
>  
>  struct btf;
> diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
> index 7c384d10e95f..bb6c969a114a 100644
> --- a/tools/bpf/bpftool/pids.c
> +++ b/tools/bpf/bpftool/pids.c
> @@ -78,6 +78,8 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
>  	ref->pid = e->pid;
>  	memcpy(ref->comm, e->comm, sizeof(ref->comm));
>  	refs->ref_cnt = 1;
> +	refs->has_bpf_cookie = e->has_bpf_cookie;
> +	refs->bpf_cookie = e->bpf_cookie;
>  
>  	err = hashmap__append(map, u32_as_hash_field(e->id), refs);
>  	if (err)
> @@ -205,6 +207,9 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
>  		if (refs->ref_cnt == 0)
>  			break;
>  
> +		if (refs->has_bpf_cookie)
> +			jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> +

Thinking again about this patch, shouldn't the JSON output for the
cookie(s) be an array if we expect to have several cookies for
multi-attach links in the future?

Quentin

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-26  1:38 ` Quentin Monnet
@ 2022-03-26  9:08   ` Dmitry Dolgov
  2022-03-27 22:03     ` Quentin Monnet
  0 siblings, 1 reply; 11+ messages in thread
From: Dmitry Dolgov @ 2022-03-26  9:08 UTC (permalink / raw)
  To: Quentin Monnet; +Cc: bpf, ast, daniel, andrii, yhs

> On Sat, Mar 26, 2022 at 01:38:36AM +0000, Quentin Monnet wrote:
> 2022-03-09 17:31 UTC+0100 ~ Dmitrii Dolgov <9erthalion6@gmail.com>
> > 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.
> >
> > [...]
> >
> > diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
> > index 7c384d10e95f..bb6c969a114a 100644
> > --- a/tools/bpf/bpftool/pids.c
> > +++ b/tools/bpf/bpftool/pids.c
> > @@ -78,6 +78,8 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> >  	ref->pid = e->pid;
> >  	memcpy(ref->comm, e->comm, sizeof(ref->comm));
> >  	refs->ref_cnt = 1;
> > +	refs->has_bpf_cookie = e->has_bpf_cookie;
> > +	refs->bpf_cookie = e->bpf_cookie;
> >
> >  	err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> >  	if (err)
> > @@ -205,6 +207,9 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> >  		if (refs->ref_cnt == 0)
> >  			break;
> >
> > +		if (refs->has_bpf_cookie)
> > +			jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> > +
>
> Thinking again about this patch, shouldn't the JSON output for the
> cookie(s) be an array if we expect to have several cookies for
> multi-attach links in the future?

Interesting point. My impression is that this could be done together
with the other changes about making multi-attach links possible (I
didn't miss anything, it's not yet implemented, right?). On the other
hand I'm planning to prepare few more patches in similar direction -- so
if everyone agrees it has to be extended to an array now, I can tackle
this as well.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-26  9:08   ` Dmitry Dolgov
@ 2022-03-27 22:03     ` Quentin Monnet
  2022-03-28 13:06       ` Dmitry Dolgov
  2022-03-28 21:39       ` Andrii Nakryiko
  0 siblings, 2 replies; 11+ messages in thread
From: Quentin Monnet @ 2022-03-27 22:03 UTC (permalink / raw)
  To: Dmitry Dolgov; +Cc: bpf, ast, daniel, andrii, yhs

2022-03-26 10:08 UTC+0100 ~ Dmitry Dolgov <9erthalion6@gmail.com>
>> On Sat, Mar 26, 2022 at 01:38:36AM +0000, Quentin Monnet wrote:
>> 2022-03-09 17:31 UTC+0100 ~ Dmitrii Dolgov <9erthalion6@gmail.com>
>>> 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.
>>>
>>> [...]
>>>
>>> diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
>>> index 7c384d10e95f..bb6c969a114a 100644
>>> --- a/tools/bpf/bpftool/pids.c
>>> +++ b/tools/bpf/bpftool/pids.c
>>> @@ -78,6 +78,8 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
>>>  	ref->pid = e->pid;
>>>  	memcpy(ref->comm, e->comm, sizeof(ref->comm));
>>>  	refs->ref_cnt = 1;
>>> +	refs->has_bpf_cookie = e->has_bpf_cookie;
>>> +	refs->bpf_cookie = e->bpf_cookie;
>>>
>>>  	err = hashmap__append(map, u32_as_hash_field(e->id), refs);
>>>  	if (err)
>>> @@ -205,6 +207,9 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
>>>  		if (refs->ref_cnt == 0)
>>>  			break;
>>>
>>> +		if (refs->has_bpf_cookie)
>>> +			jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
>>> +
>>
>> Thinking again about this patch, shouldn't the JSON output for the
>> cookie(s) be an array if we expect to have several cookies for
>> multi-attach links in the future?
> 
> Interesting point. My impression is that this could be done together
> with the other changes about making multi-attach links possible (I
> didn't miss anything, it's not yet implemented, right?). On the other
> hand I'm planning to prepare few more patches in similar direction -- so
> if everyone agrees it has to be extended to an array now, I can tackle
> this as well.

Correct, it's not implemented yet for multi-attach links. My concern
here is to avoid changing the JSON structure in the future (to avoid
breaking changes for tools that would process the JSON). If we know
we're likely to have several cookies in the future, it may be worth
using an array “from start” (since no version has been tagged yet after
you added support for the cookie).

Quentin

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-27 22:03     ` Quentin Monnet
@ 2022-03-28 13:06       ` Dmitry Dolgov
  2022-03-28 21:39       ` Andrii Nakryiko
  1 sibling, 0 replies; 11+ messages in thread
From: Dmitry Dolgov @ 2022-03-28 13:06 UTC (permalink / raw)
  To: Quentin Monnet; +Cc: bpf, ast, daniel, andrii, yhs

> On Sun, Mar 27, 2022 at 11:03:49PM +0100, Quentin Monnet wrote:
>
> Correct, it's not implemented yet for multi-attach links. My concern
> here is to avoid changing the JSON structure in the future (to avoid
> breaking changes for tools that would process the JSON). If we know
> we're likely to have several cookies in the future, it may be worth
> using an array “from start” (since no version has been tagged yet after
> you added support for the cookie).

Yep, sounds convincing enough to me, will prepare the chance shortly.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output
  2022-03-27 22:03     ` Quentin Monnet
  2022-03-28 13:06       ` Dmitry Dolgov
@ 2022-03-28 21:39       ` Andrii Nakryiko
  1 sibling, 0 replies; 11+ messages in thread
From: Andrii Nakryiko @ 2022-03-28 21:39 UTC (permalink / raw)
  To: Quentin Monnet
  Cc: Dmitry Dolgov, bpf, Alexei Starovoitov, Daniel Borkmann,
	Andrii Nakryiko, Yonghong Song

On Sun, Mar 27, 2022 at 3:03 PM Quentin Monnet <quentin@isovalent.com> wrote:
>
> 2022-03-26 10:08 UTC+0100 ~ Dmitry Dolgov <9erthalion6@gmail.com>
> >> On Sat, Mar 26, 2022 at 01:38:36AM +0000, Quentin Monnet wrote:
> >> 2022-03-09 17:31 UTC+0100 ~ Dmitrii Dolgov <9erthalion6@gmail.com>
> >>> 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.
> >>>
> >>> [...]
> >>>
> >>> diff --git a/tools/bpf/bpftool/pids.c b/tools/bpf/bpftool/pids.c
> >>> index 7c384d10e95f..bb6c969a114a 100644
> >>> --- a/tools/bpf/bpftool/pids.c
> >>> +++ b/tools/bpf/bpftool/pids.c
> >>> @@ -78,6 +78,8 @@ static void add_ref(struct hashmap *map, struct pid_iter_entry *e)
> >>>     ref->pid = e->pid;
> >>>     memcpy(ref->comm, e->comm, sizeof(ref->comm));
> >>>     refs->ref_cnt = 1;
> >>> +   refs->has_bpf_cookie = e->has_bpf_cookie;
> >>> +   refs->bpf_cookie = e->bpf_cookie;
> >>>
> >>>     err = hashmap__append(map, u32_as_hash_field(e->id), refs);
> >>>     if (err)
> >>> @@ -205,6 +207,9 @@ void emit_obj_refs_json(struct hashmap *map, __u32 id,
> >>>             if (refs->ref_cnt == 0)
> >>>                     break;
> >>>
> >>> +           if (refs->has_bpf_cookie)
> >>> +                   jsonw_lluint_field(json_writer, "bpf_cookie", refs->bpf_cookie);
> >>> +
> >>
> >> Thinking again about this patch, shouldn't the JSON output for the
> >> cookie(s) be an array if we expect to have several cookies for
> >> multi-attach links in the future?
> >
> > Interesting point. My impression is that this could be done together
> > with the other changes about making multi-attach links possible (I
> > didn't miss anything, it's not yet implemented, right?). On the other
> > hand I'm planning to prepare few more patches in similar direction -- so
> > if everyone agrees it has to be extended to an array now, I can tackle
> > this as well.
>
> Correct, it's not implemented yet for multi-attach links. My concern
> here is to avoid changing the JSON structure in the future (to avoid
> breaking changes for tools that would process the JSON). If we know
> we're likely to have several cookies in the future, it may be worth
> using an array “from start” (since no version has been tagged yet after
> you added support for the cookie).

The problem with multi-cookie links (like KPROBE_MULTI that was merged
a week ago) is that cookies by themselves are not that helpful. Also,
internally we change their order to be sorted according to resolved
kernel function addresses. So just an array of cookies are not enough,
but asking kernel to preserve all the addresses just for the sake of
reporting them in bpftool seems to much.

So in general, with multi-cookie links, it's not clear what you should
report at all.

>
> Quentin

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-03-28 22:14 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-09 16:31 [PATCH bpf-next v6] bpftool: Add bpf_cookie to link output Dmitrii Dolgov
2022-03-11 22:24 ` Andrii Nakryiko
2022-03-12 22:59   ` Quentin Monnet
2022-03-15 18:33     ` Andrii Nakryiko
2022-03-15 21:01       ` Quentin Monnet
2022-03-15 22:10 ` patchwork-bot+netdevbpf
2022-03-26  1:38 ` Quentin Monnet
2022-03-26  9:08   ` Dmitry Dolgov
2022-03-27 22:03     ` Quentin Monnet
2022-03-28 13:06       ` Dmitry Dolgov
2022-03-28 21:39       ` Andrii Nakryiko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.