All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Chen <chen.dylane@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Matt Bobrowski <mattbobrowski@google.com>,
	Song Liu <song@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard <eddyz87@gmail.com>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	bpf <bpf@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
	linux-trace-kernel <linux-trace-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v5 1/3] bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo
Date: Wed, 25 Jun 2025 00:12:56 +0800	[thread overview]
Message-ID: <5a772bf2-aeef-4dad-881a-a7684f6b5dfc@linux.dev> (raw)
In-Reply-To: <CAEf4BzY7TZRjxpCJM-+LYgEqe23YFj5Uv3isb7gat2-HU4OSng@mail.gmail.com>

在 2025/6/24 23:46, Andrii Nakryiko 写道:
> On Tue, Jun 24, 2025 at 1:41 AM Tao Chen <chen.dylane@linux.dev> wrote:
>>
>> 在 2025/6/24 16:16, Jiri Olsa 写道:
>>> On Mon, Jun 23, 2025 at 01:59:18PM -0700, Andrii Nakryiko wrote:
>>>> On Mon, Jun 23, 2025 at 10:56 AM Alexei Starovoitov
>>>> <alexei.starovoitov@gmail.com> wrote:
>>>>>
>>>>> On Mon, Jun 23, 2025 at 6:44 AM Tao Chen <chen.dylane@linux.dev> wrote:
>>>>>>
>>>>>> Alexei suggested, 'link_type' can be more precise and differentiate
>>>>>> for human in fdinfo. In fact BPF_LINK_TYPE_KPROBE_MULTI includes
>>>>>> kretprobe_multi type, the same as BPF_LINK_TYPE_UPROBE_MULTI, so we
>>>>>> can show it more concretely.
>>>>>>
>>>>>> link_type:      kprobe_multi
>>>>>> link_id:        1
>>>>>> prog_tag:       d2b307e915f0dd37
>>>>>> ...
>>>>>> link_type:      kretprobe_multi
>>>>>> link_id:        2
>>>>>> prog_tag:       ab9ea0545870781d
>>>>>> ...
>>>>>> link_type:      uprobe_multi
>>>>>> link_id:        9
>>>>>> prog_tag:       e729f789e34a8eca
>>>>>> ...
>>>>>> link_type:      uretprobe_multi
>>>>>> link_id:        10
>>>>>> prog_tag:       7db356c03e61a4d4
>>>>>>
>>>>>> Signed-off-by: Tao Chen <chen.dylane@linux.dev>
>>>>>> ---
>>>>>>    include/linux/trace_events.h | 10 ++++++++++
>>>>>>    kernel/bpf/syscall.c         |  9 ++++++++-
>>>>>>    kernel/trace/bpf_trace.c     | 28 ++++++++++++++++++++++++++++
>>>>>>    3 files changed, 46 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> Change list:
>>>>>>     v4 -> v5:
>>>>>>       - Add patch1 to show precise link_type for
>>>>>>         {uprobe,kprobe}_multi.(Alexei)
>>>>>>       - patch2,3 just remove type field, which will be showed in
>>>>>>         link_type
>>>>>>     v4:
>>>>>>     https://lore.kernel.org/bpf/20250619034257.70520-1-chen.dylane@linux.dev
>>>>>>
>>>>>>     v3 -> v4:
>>>>>>       - use %pS to print func info.(Alexei)
>>>>>>     v3:
>>>>>>     https://lore.kernel.org/bpf/20250616130233.451439-1-chen.dylane@linux.dev
>>>>>>
>>>>>>     v2 -> v3:
>>>>>>       - show info in one line for multi events.(Jiri)
>>>>>>     v2:
>>>>>>     https://lore.kernel.org/bpf/20250615150514.418581-1-chen.dylane@linux.dev
>>>>>>
>>>>>>     v1 -> v2:
>>>>>>       - replace 'func_cnt' with 'uprobe_cnt'.(Andrii)
>>>>>>       - print func name is more readable and security for kprobe_multi.(Alexei)
>>>>>>     v1:
>>>>>>     https://lore.kernel.org/bpf/20250612115556.295103-1-chen.dylane@linux.dev
>>>>>>
>>>>>> diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
>>>>>> index fa9cf4292df..951c91babbc 100644
>>>>>> --- a/include/linux/trace_events.h
>>>>>> +++ b/include/linux/trace_events.h
>>>>>> @@ -780,6 +780,8 @@ int bpf_get_perf_event_info(const struct perf_event *event, u32 *prog_id,
>>>>>>                               unsigned long *missed);
>>>>>>    int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *prog);
>>>>>>    int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *prog);
>>>>>> +void bpf_kprobe_multi_link_type_show(const struct bpf_link *link, char *link_type, int len);
>>>>>> +void bpf_uprobe_multi_link_type_show(const struct bpf_link *link, char *link_type, int len);
>>>>>>    #else
>>>>>>    static inline unsigned int trace_call_bpf(struct trace_event_call *call, void *ctx)
>>>>>>    {
>>>>>> @@ -832,6 +834,14 @@ bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
>>>>>>    {
>>>>>>           return -EOPNOTSUPP;
>>>>>>    }
>>>>>> +static inline void
>>>>>> +bpf_kprobe_multi_link_type_show(const struct bpf_link *link, char *link_type, int len)
>>>>>> +{
>>>>>> +}
>>>>>> +static inline void
>>>>>> +bpf_uprobe_multi_link_type_show(const struct bpf_link *link, char *link_type, int len)
>>>>>> +{
>>>>>> +}
>>>>>>    #endif
>>>>>>
>>>>>>    enum {
>>>>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>>>>> index 51ba1a7aa43..43b821b37bc 100644
>>>>>> --- a/kernel/bpf/syscall.c
>>>>>> +++ b/kernel/bpf/syscall.c
>>>>>> @@ -3226,9 +3226,16 @@ static void bpf_link_show_fdinfo(struct seq_file *m, struct file *filp)
>>>>>>           const struct bpf_prog *prog = link->prog;
>>>>>>           enum bpf_link_type type = link->type;
>>>>>>           char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
>>>>>> +       char link_type[64] = {};
>>>>>>
>>>>>>           if (type < ARRAY_SIZE(bpf_link_type_strs) && bpf_link_type_strs[type]) {
>>>>>> -               seq_printf(m, "link_type:\t%s\n", bpf_link_type_strs[type]);
>>>>>> +               if (link->type == BPF_LINK_TYPE_KPROBE_MULTI)
>>>>>> +                       bpf_kprobe_multi_link_type_show(link, link_type, sizeof(link_type));
>>>>>> +               else if (link->type == BPF_LINK_TYPE_UPROBE_MULTI)
>>>>>> +                       bpf_uprobe_multi_link_type_show(link, link_type, sizeof(link_type));
>>>>>> +               else
>>>>>> +                       strscpy(link_type, bpf_link_type_strs[type], sizeof(link_type));
>>>>>> +               seq_printf(m, "link_type:\t%s\n", link_type);
>>>>>
>>>>> New callbacks just to print a string?
>>>>> Let's find a different way.
>>>>>
>>>>> How about moving 'flags' from bpf_[ku]probe_multi_link into bpf_link ?
>>>>> (There is a 7 byte hole there anyway)
>>>>> and checking flags inline.
>>>>>
>>>>> Jiri, Andrii,
>>>>>
>>>>> better ideas?
>>>>
>>>> We can just remember original attr->link_create.attach_type in
>>>> bpf_link itself, and then have a small helper that will accept link
>>>> type and attach type, and fill out link type representation based on
>>>> those two. Internally we can do the special-casing of  uprobe vs
>>>> uretprobe and kprobe vs kretprobe transparently to all the other code.
>>>> And use that here in show_fdinfo
>>>
>>> but you'd still need the flags, no? to find out if it's return probe
>>>
>>> I tried what Alexei suggested and it seems ok and simple enough
>>>
>>> jirka
>>>
>>>
>>> ---
>>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>>> index 5dd556e89cce..287c956cdbd2 100644
>>> --- a/include/linux/bpf.h
>>> +++ b/include/linux/bpf.h
>>> @@ -1702,6 +1702,7 @@ struct bpf_link {
>>>         * link's semantics is determined by target attach hook
>>>         */
>>>        bool sleepable;
>>> +     u32 flags;
>>>        /* rcu is used before freeing, work can be used to schedule that
>>>         * RCU-based freeing before that, so they never overlap
>>>         */
>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>> index 56500381c28a..f1d9ee9717a1 100644
>>> --- a/kernel/bpf/syscall.c
>>> +++ b/kernel/bpf/syscall.c
>>> @@ -3228,7 +3228,14 @@ static void bpf_link_show_fdinfo(struct seq_file *m, struct file *filp)
>>>        char prog_tag[sizeof(prog->tag) * 2 + 1] = { };
>>>
>>>        if (type < ARRAY_SIZE(bpf_link_type_strs) && bpf_link_type_strs[type]) {
>>> -             seq_printf(m, "link_type:\t%s\n", bpf_link_type_strs[type]);
>>> +             if (link->type == BPF_LINK_TYPE_KPROBE_MULTI)
>>> +                     seq_printf(m, "link_type:\t%s\n", link->flags == BPF_F_KPROBE_MULTI_RETURN ?
>>> +                                "kretprobe_multi" : "kprobe_multi");
>>> +             else if (link->type == BPF_LINK_TYPE_UPROBE_MULTI)
>>> +                     seq_printf(m, "link_type:\t%s\n", link->flags == BPF_F_UPROBE_MULTI_RETURN ?
>>> +                                "uretprobe_multi" : "uprobe_multi");
>>> +             else
>>> +                     seq_printf(m, "link_type:\t%s\n", bpf_link_type_strs[type]);
>>>        } else {
>>>                WARN_ONCE(1, "missing BPF_LINK_TYPE(...) for link type %u\n", type);
>>>                seq_printf(m, "link_type:\t<%u>\n", type);
>>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
>>> index 0a06ea6638fe..81d7a4e5ae15 100644
>>> --- a/kernel/trace/bpf_trace.c
>>> +++ b/kernel/trace/bpf_trace.c
>>> @@ -2466,7 +2466,6 @@ struct bpf_kprobe_multi_link {
>>>        u32 cnt;
>>>        u32 mods_cnt;
>>>        struct module **mods;
>>> -     u32 flags;
>>>    };
>>>
>>>    struct bpf_kprobe_multi_run_ctx {
>>> @@ -2586,7 +2585,7 @@ static int bpf_kprobe_multi_link_fill_link_info(const struct bpf_link *link,
>>>
>>>        kmulti_link = container_of(link, struct bpf_kprobe_multi_link, link);
>>>        info->kprobe_multi.count = kmulti_link->cnt;
>>> -     info->kprobe_multi.flags = kmulti_link->flags;
>>> +     info->kprobe_multi.flags = kmulti_link->link.flags;
>>>        info->kprobe_multi.missed = kmulti_link->fp.nmissed;
>>>
>>>        if (!uaddrs)
>>> @@ -2976,7 +2975,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>>>        link->addrs = addrs;
>>>        link->cookies = cookies;
>>>        link->cnt = cnt;
>>> -     link->flags = flags;
>>> +     link->link.flags = flags;
>>>
>>>        if (cookies) {
>>>                /*
>>> @@ -3045,7 +3044,6 @@ struct bpf_uprobe_multi_link {
>>>        struct path path;
>>>        struct bpf_link link;
>>>        u32 cnt;
>>> -     u32 flags;
>>>        struct bpf_uprobe *uprobes;
>>>        struct task_struct *task;
>>>    };
>>> @@ -3109,7 +3107,7 @@ static int bpf_uprobe_multi_link_fill_link_info(const struct bpf_link *link,
>>>
>>>        umulti_link = container_of(link, struct bpf_uprobe_multi_link, link);
>>>        info->uprobe_multi.count = umulti_link->cnt;
>>> -     info->uprobe_multi.flags = umulti_link->flags;
>>> +     info->uprobe_multi.flags = umulti_link->link.flags;
>>>        info->uprobe_multi.pid = umulti_link->task ?
>>>                                 task_pid_nr_ns(umulti_link->task, task_active_pid_ns(current)) : 0;
>>>
>>> @@ -3369,7 +3367,7 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>>>        link->uprobes = uprobes;
>>>        link->path = path;
>>>        link->task = task;
>>> -     link->flags = flags;
>>> +     link->link.flags = flags;
>>>
>>>        bpf_link_init(&link->link, BPF_LINK_TYPE_UPROBE_MULTI,
>>>                      &bpf_uprobe_multi_link_lops, prog);
>>
>> Hi, Jiri, Andrii,
>>
>> Jiri's patch looks more simple, and i see other struct xx_links wrap
>> bpf_link, which have attach_type field like:
>> struct sockmap_link {
>>           struct bpf_link link;
>>           struct bpf_map *map;
>>           enum bpf_attach_type attach_type;
>> };
>> If we create attach_type filed in bpf_link, maybe these struct xx_link
>> should also be modified. BTW, as Jiri said, we still can not find return
>> probe type from attach_type.
> 
> You are right, I somehow was under impression that ret vs non-retprobe
> comes from attach type as well.
> 
> Ok, moving flags into common bpf_link struct sounds good to me. I'd
> still move attach_type into bpf_link, together with flags, for
> generality (and update all those links that already include
> attach_type as you mentioned). We can make it a single-byte field to
> not increase bpf_link size unnecessarily (by using bitfield size).
> 

Well,can we complete this in two steps?

1. Create a common field in bpf_link used for flags or attach_type, and 
realise the precise link_type feature as Jiri and Alexei said, the 
review of this part has been revised almost completely.

2. Move the attach_type from struct bpf_xx_link into bpf_link, this will 
involve a lot of changes, i will send a separate patchset to finish it.

>>
>> --
>> Best Regards
>> Tao Chen


-- 
Best Regards
Tao Chen

  reply	other threads:[~2025-06-24 16:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-23 13:43 [PATCH bpf-next v5 1/3] bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo Tao Chen
2025-06-23 13:43 ` [PATCH bpf-next v5 2/3] bpf: Add show_fdinfo for uprobe_multi Tao Chen
2025-06-23 22:14   ` Andrii Nakryiko
2025-06-24  8:42     ` Tao Chen
2025-06-23 13:43 ` [PATCH bpf-next v5 3/3] bpf: Add show_fdinfo for kprobe_multi Tao Chen
2025-06-23 17:55 ` [PATCH bpf-next v5 1/3] bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo Alexei Starovoitov
2025-06-23 20:59   ` Andrii Nakryiko
2025-06-24  8:16     ` Jiri Olsa
2025-06-24  8:41       ` Tao Chen
2025-06-24 15:46         ` Andrii Nakryiko
2025-06-24 16:12           ` Tao Chen [this message]
2025-06-24 19:41             ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5a772bf2-aeef-4dad-881a-a7684f6b5dfc@linux.dev \
    --to=chen.dylane@linux.dev \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mattbobrowski@google.com \
    --cc=mhiramat@kernel.org \
    --cc=olsajiri@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.