linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Francis Laniel <flaniel@linux.microsoft.com>
To: Masahiro Yamada <masahiroy@kernel.org>,
	Alessandro Carminati <alessandro.carminati@gmail.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Bristot de Oliveira <bristot@kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nicolas Schier <nicolas@fjasle.eu>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	Nick Alcock <nick.alcock@oracle.com>,
	Kris Van Hees <kris.van.hees@oracle.com>,
	Eugene Loh <eugene.loh@oracle.com>,
	Viktor Malik <vmalik@redhat.com>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	live-patching@vger.kernel.org
Subject: Re: [PATCH v3] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Date: Mon, 04 Sep 2023 15:09:12 +0200	[thread overview]
Message-ID: <12278120.O9o76ZdvQC@pwmachine> (raw)
In-Reply-To: <CAPp5cGTngA6_zhPpgMGsvp8T49LZEohzyRtedGSo8hkEJFRkiA@mail.gmail.com>

Hi.

Le samedi 2 septembre 2023, 09:40:46 CEST Alessandro Carminati a écrit :
> Il giorno sab 2 set 2023 alle ore 08:36 Masahiro Yamada
> 
> <masahiroy@kernel.org> ha scritto:
> > On Mon, Aug 28, 2023 at 8:45 PM Alessandro Carminati (Red Hat)
> > 
> > <alessandro.carminati@gmail.com> wrote:
> > > From: Alessandro Carminati <alessandro.carminati@gmail.com>
> > > 
> > > It is not uncommon for drivers or modules related to similar peripherals
> > > to have symbols with the exact same name.
> > > While this is not a problem for the kernel's binary itself, it becomes
> > > an
> > > issue when attempting to trace or probe specific functions using
> > > infrastructure like ftrace or kprobe.
> > > 
> > > The tracing subsystem relies on the `nm -n vmlinux` output, which
> > > provides
> > > symbol information from the kernel's ELF binary. However, when multiple
> > > symbols share the same name, the standard nm output does not
> > > differentiate
> > > between them. This can lead to confusion and difficulty when trying to
> > > probe the intended symbol.
> > > 
> > >  ~ # cat /proc/kallsyms | grep " name_show"
> > >  ffffffff8c4f76d0 t name_show
> > >  ffffffff8c9cccb0 t name_show
> > >  ffffffff8cb0ac20 t name_show
> > >  ffffffff8cc728c0 t name_show
> > >  ffffffff8ce0efd0 t name_show
> > >  ffffffff8ce126c0 t name_show
> > >  ffffffff8ce1dd20 t name_show
> > >  ffffffff8ce24e70 t name_show
> > >  ffffffff8d1104c0 t name_show
> > >  ffffffff8d1fe480 t name_show
> > > 
> > > **kas_alias** addresses this challenge by extending the symbol names
> > > with
> > > unique suffixes during the kernel build process.
> > > The newly created aliases for these duplicated symbols are unique names
> > > that can be fed to the ftracefs interface. By doing so, it enables
> > > previously unreachable symbols to be probed.
> > > 
> > >  ~ # cat /proc/kallsyms | grep " name_show"
> > >  ffffffff974f76d0 t name_show
> > >  ffffffff974f76d0 t name_show__alias__6340
> > >  ffffffff979cccb0 t name_show
> > >  ffffffff979cccb0 t name_show__alias__6341
> > >  ffffffff97b0ac20 t name_show
> > >  ffffffff97b0ac20 t name_show__alias__6342
> > >  ffffffff97c728c0 t name_show
> > >  ffffffff97c728c0 t name_show__alias__6343
> > >  ffffffff97e0efd0 t name_show
> > >  ffffffff97e0efd0 t name_show__alias__6344
> > >  ffffffff97e126c0 t name_show
> > >  ffffffff97e126c0 t name_show__alias__6345
> > >  ffffffff97e1dd20 t name_show
> > >  ffffffff97e1dd20 t name_show__alias__6346
> > >  ffffffff97e24e70 t name_show
> > >  ffffffff97e24e70 t name_show__alias__6347
> > >  ffffffff981104c0 t name_show
> > >  ffffffff981104c0 t name_show__alias__6348
> > >  ffffffff981fe480 t name_show
> > >  ffffffff981fe480 t name_show__alias__6349
> > >  ~ # echo "p:kprobes/evnt1 name_show__alias__6349" \
> > >  
> > >  > >/sys/kernel/tracing/kprobe_events
> > >  
> > >  ~ # cat /sys/kernel/tracing/kprobe_events
> > >  p:kprobes/evnt1 name_show__alias__6349
> > > 
> > > Changes from v1:
> > > - Integrated changes requested by Masami to exclude symbols with
> > > prefixes
> > > 
> > >   "_cfi" and "_pfx".
> > > 
> > > - Introduced a small framework to handle patterns that need to be
> > > excluded
> > > 
> > >   from the alias production.
> > > 
> > > - Excluded other symbols using the framework.
> > > - Introduced the ability to discriminate between text and data symbols.
> > > - Added two new config symbols in this version:
> > > CONFIG_KALLSYMS_ALIAS_DATA,
> > > 
> > >   which allows data for data, and CONFIG_KALLSYMS_ALIAS_DATA_ALL, which
> > >   excludes all filters and provides an alias for each duplicated symbol.
> > > 
> > > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carminat
> > > i@gmail.com/
> > > 
> > > Changes from v2:
> > > - Alias tags are created by querying DWARF information from the vmlinux.
> > > - The filename + line number is normalized and appended to the original
> > > name. - The tag begins with '@' to indicate the symbol source.
> > > - Not a change, but worth mentioning, since the alias is added to the
> > > existing> > 
> > >   list, the old duplicated name is preserved, and the livepatch way of
> > >   dealing with duplicates is maintained.
> > > 
> > > - Acknowledging the existence of scenarios where inlined functions
> > > declared in> > 
> > >   header files may result in multiple copies due to compiler behavior,
> > >   though
> > >   
> > >    it is not actionable as it does not pose an operational issue.
> > > 
> > > - Highlighting a single exception where the same name refers to
> > > different
> > > 
> > >   functions: the case of "compat_binfmt_elf.c," which directly includes
> > >   "binfmt_elf.c" producing identical function copies in two separate
> > >   modules.
> > > 
> > > sample from new v3
> > > 
> > >  ~ # cat /proc/kallsyms | grep gic_mask_irq
> > >  ffffd0b03c04dae4 t gic_mask_irq
> > >  ffffd0b03c04dae4 t gic_mask_irq@_drivers_irqchip_irq-gic_c_167
> > >  ffffd0b03c050960 t gic_mask_irq
> > >  ffffd0b03c050960 t gic_mask_irq@_drivers_irqchip_irq-gic-v3_c_404
> > >  ~ #
> > > 
> > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carminat
> > > i@gmail.com/
> > > 
> > > Signed-off-by: Alessandro Carminati (Red Hat)
> > > <alessandro.carminati@gmail.com> ---
> > > 
> > >  init/Kconfig                        |  36 ++++
> > >  scripts/Makefile                    |   4 +
> > >  scripts/kas_alias/Makefile          |   4 +
> > >  scripts/kas_alias/a2l.c             | 268 ++++++++++++++++++++++++++++
> > >  scripts/kas_alias/a2l.h             |  32 ++++
> > >  scripts/kas_alias/duplicates_list.c |  70 ++++++++
> > >  scripts/kas_alias/duplicates_list.h |  15 ++
> > >  scripts/kas_alias/item_list.c       | 230 ++++++++++++++++++++++++
> > >  scripts/kas_alias/item_list.h       |  26 +++
> > >  scripts/kas_alias/kas_alias.c       | 217 ++++++++++++++++++++++
> > >  scripts/link-vmlinux.sh             |  11 +-
> > >  11 files changed, 910 insertions(+), 3 deletions(-)
> > 
> > I added some review comments in another thread, but
> > one of the biggest concerns might be "910 insertions".
> 
> Based on the feedback I received in the reviews, I need to overhaul the
> code, potentially reducing its size. What would be a reasonable number
> of lines for this feature?
> 
> > What this program does is quite simple,
> > "find duplicated names, and call addr2line".
> > 
> > You wrote a lot of code to self-implement these:
> >  - sort function
> >  - parse PATH env variable to find addr2line
> >  - fork addr2line to establish pipe communications
> 
> Some of these functions might become obsolete in the upcoming v4, which
> will certainly reduce the line count.
> 
> > Have you considered writing the code in Python (or Perl)?
> > Is it too slow?
> >
> >From my perspective, there is a concern that using Python or Perl might
> 
> result in slower performance. My proficiency in Python and Perl is
> limited, so I did not initially consider them as viable options for
> implementing this solution.
> 
> > Most of the functions you implemented are already
> > available in script languages.
> > 
> > 
> > 
> > I am not sure if "@<file-path>" is a good solution,
> > but the amount of the added code looks too much to me.
> 
> I had reservations about using the '@' symbol to decorate the alias because
> it's not a character commonly found in the kallsyms output. However, after
> careful consideration, I arrived at the conclusion that it was suitable for
> the task because it would make the alias stand-out and be easily
> identifiable.
> I'm open to any suggestions or alternative approaches you may have on this
> matter.

I am maybe over-engineering the thing, but maybe we can have a 
CONFIG_KALLSYMS_ALIAS_FORMAT which users would set to indicate how to 
differentiate between two symbols?
For example, CONFIG_KALLSYMS_ALIAS_FORMAT=@file-lineno would lead to what we 
have currently.
If you switch to using a higher level language, you can maybe focus more on 
this.
Anyway, I personally like what this contribution offers currently as it permits 
to distinguish between same symbols.
I will take a look at v4! Thank you again for working on this.

> > --
> > Best Regards
> > Masahiro Yamada
> 
> Thank you

Best regards.



  reply	other threads:[~2023-09-04 13:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-28  8:04 [PATCH v3] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms Alessandro Carminati (Red Hat)
2023-08-29 14:51 ` Francis Laniel
2023-09-02  7:26   ` Alessandro Carminati
2023-08-30  6:00 ` Masami Hiramatsu
2023-09-02  7:26   ` Alessandro Carminati
2023-09-03 14:50     ` Masami Hiramatsu
2023-09-01  5:31 ` Masahiro Yamada
2023-09-02  7:27   ` Alessandro Carminati
2023-09-02  6:36 ` Masahiro Yamada
2023-09-02  7:40   ` Alessandro Carminati
2023-09-04 13:09     ` Francis Laniel [this message]
2023-09-06 10:09   ` Alessandro Carminati
2023-09-06 15:06     ` Masahiro Yamada
2023-09-11 14:21 ` Alexander Lobakin
2023-09-12 14:18   ` Alessandro Carminati
2023-09-13  8:06     ` Petr Mladek

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=12278120.O9o76ZdvQC@pwmachine \
    --to=flaniel@linux.microsoft.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=alessandro.carminati@gmail.com \
    --cc=bristot@kernel.org \
    --cc=eugene.loh@oracle.com \
    --cc=jpoimboe@kernel.org \
    --cc=kris.van.hees@oracle.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nick.alcock@oracle.com \
    --cc=nicolas@fjasle.eu \
    --cc=rostedt@goodmis.org \
    --cc=vmalik@redhat.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).