bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
	ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
	andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
	yhs@fb.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, quentin@isovalent.com, bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 1/8] bpf: Support ->show_fdinfo for kprobe_multi
Date: Tue, 30 May 2023 17:28:58 -0700	[thread overview]
Message-ID: <20230531002858.aiyahbvwpenjsr27@MacBook-Pro-8.local> (raw)
In-Reply-To: <CALOAHbDTiPvawvS5xegiLVERzjh2MgmusDQFhCcfLY=wzw=oTA@mail.gmail.com>

On Tue, May 30, 2023 at 09:39:01AM +0800, Yafang Shao wrote:
> On Mon, May 29, 2023 at 8:06 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Sun, May 28, 2023 at 02:20:20PM +0000, Yafang Shao wrote:
> > > Currently, there is no way to check which functions are attached to a
> > > kprobe_multi link, causing confusion for users. It is important that we
> > > provide a means to expose these functions. The expected result is as follows,
> > >
> > > $ cat /proc/10936/fdinfo/9
> > > pos:    0
> > > flags:  02000000
> > > mnt_id: 15
> > > ino:    2094
> > > link_type:      kprobe_multi
> > > link_id:        2
> > > prog_tag:       a04f5eef06a7f555
> > > prog_id:        11
> > > func_count:     4
> > > func_addrs:     ffffffffaad475c0
> > >                 ffffffffaad47600
> > >                 ffffffffaad47640
> > >                 ffffffffaad47680
> >
> > I like the idea of exposing this through the link_info syscall,
> > but I'm bit concerned of potentially dumping thousands of addresses
> > through fdinfo file, because I always thought of fdinfo as brief
> > file info, but that might be just my problem ;-)
> 
> In most cases, there are only a few addresses, and it is uncommon to

I doubt you have data to prove that kprobe_multi is "few addresses in most cases",
so please don't throw such arguments without proof.

> have thousands of addresses. To handle this, what about displaying a
> maximum of 16 addresses? For cases where the number of addresses
> exceeds 16, we can use '...' to represent the remaining addresses.

at this point the kernel can pick random 16 kernel funcs and it won't be
much worse.

Asking users to do
$ cat /proc/10936/fdinfo/9 | grep "func_addrs" -A 4 | \
  awk '{ if (NR ==1) {print $2} else {print $1}}' | \
  awk '{"grep " $1 " /proc/kallsyms"| getline f; print f}'
ffffffffaad475c0 T schedule_timeout_interruptible
ffffffffaad47600 T schedule_timeout_killable

isn't a great interface either.

The proper interface through fill_link_info and bpftool is good to have,
but fdinfo shouldn't partially duplicate it. So drop this patch and others.

  reply	other threads:[~2023-05-31  0:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 14:20 [RFC PATCH bpf-next 0/8] bpf: Support ->show_fdinfo and ->fill_link_info for kprobe prog Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 1/8] bpf: Support ->show_fdinfo for kprobe_multi Yafang Shao
2023-05-29 12:06   ` Jiri Olsa
2023-05-30  1:39     ` Yafang Shao
2023-05-31  0:28       ` Alexei Starovoitov [this message]
2023-05-31  3:14         ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 2/8] bpf: Support ->fill_link_info " Yafang Shao
2023-05-29 12:49   ` Jiri Olsa
2023-05-30  1:41     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 3/8] bpftool: Show probed function in kprobe_multi link info Yafang Shao
2023-05-30 11:15   ` Quentin Monnet
2023-05-31  3:16     ` Yafang Shao
2023-05-31  0:31   ` Alexei Starovoitov
2023-05-31  3:17     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 4/8] bpf: Always expose the probed address Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 5/8] bpf: Support ->show_fdinfo for perf_event Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 6/8] bpf: Add a common helper bpf_copy_to_user() Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 7/8] bpf: Support ->fill_link_info for perf_event Yafang Shao
2023-05-31  0:37   ` Alexei Starovoitov
2023-05-31  3:24     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 8/8] bpftool: Show probed function in perf_event link info Yafang Shao

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=20230531002858.aiyahbvwpenjsr27@MacBook-Pro-8.local \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=olsajiri@gmail.com \
    --cc=quentin@isovalent.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=yhs@fb.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).