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