linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Song Liu <songliubraving@meta.com>
Cc: "Leizhen (ThunderTown)" <thunder.leizhen@huaweicloud.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Song Liu <song@kernel.org>,
	"live-patching@vger.kernel.org" <live-patching@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-trace-kernel@vger.kernel.org"
	<linux-trace-kernel@vger.kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Petr Mladek <pmladek@suse.com>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Nathan Chancellor <nathan@kernel.org>,
	"morbo@google.com" <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Leizhen <thunder.leizhen@huawei.com>,
	"kees@kernel.org" <kees@kernel.org>,
	Kernel Team <kernel-team@meta.com>,
	Matthew Maurer <mmaurer@google.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without .llmv.<hash> suffix.
Date: Fri, 2 Aug 2024 22:04:27 +0900	[thread overview]
Message-ID: <20240802220427.8404fa9081b9a740c4f9cb06@kernel.org> (raw)
In-Reply-To: <FE4F231A-5D24-4337-AE00-9B251733EC53@fb.com>

Hi,

Sorry for late reply.

On Fri, 2 Aug 2024 03:45:42 +0000
Song Liu <songliubraving@meta.com> wrote:

> 
> 
> > On Aug 1, 2024, at 6:18 PM, Leizhen (ThunderTown) <thunder.leizhen@huaweicloud.com> wrote:
> > 
> > On 2024/7/31 9:00, Song Liu wrote:
> >> Hi Masami, 
> >> 
> >>> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >>> 
> >>> On Mon, 29 Jul 2024 17:54:32 -0700
> >>> Song Liu <song@kernel.org> wrote:
> >>> 
> >>>> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
> >>>> to avoid duplication. This causes confusion with users of kallsyms.
> >>>> On one hand, users like livepatch are required to match the symbols
> >>>> exactly. On the other hand, users like kprobe would like to match to
> >>>> original function names.
> >>>> 
> >>>> Solve this by splitting kallsyms APIs. Specifically, existing APIs now
> >>>> should match the symbols exactly. Add two APIs that matches the full
> >>>> symbol, or only the part without .llvm.suffix. Specifically, the following
> >>>> two APIs are added:
> >>>> 
> >>>> 1. kallsyms_lookup_name_or_prefix()
> >>>> 2. kallsyms_on_each_match_symbol_or_prefix()
> >>> 
> >>> Since this API only removes the suffix, "match prefix" is a bit confusing.
> >>> (this sounds like matching "foo" with "foo" and "foo_bar", but in reality,
> >>> it only matches "foo" and "foo.llvm.*")
> >>> What about the name below?
> >>> 
> >>> kallsyms_lookup_name_without_suffix()
> >>> kallsyms_on_each_match_symbol_without_suffix()
> >> 
> >> I am open to name suggestions. I named it as xx or prefix to highlight
> >> that these two APIs will try match full name first, and they only match
> >> the symbol without suffix when there is no full name match. 
> >> 
> >> Maybe we can call them: 
> >> - kallsyms_lookup_name_or_without_suffix()
> >> - kallsyms_on_each_match_symbol_or_without_suffix()

No, I think "_or_without_suffix" is a bit complicated. If we have

0x1234 "foo.llvm.XXX"
0x2356 "bar"

and user calls

  kallsyms_lookup_name_without_suffix("bar");

This returns "bar"'s address(0x2356). Also,

  kallsyms_lookup_name_without_suffix("foo");

this will returns 0x1234. These commonly just ignore the suffix.
The difference of kallsyms_lookup_name() is that point.

> >> 
> >> Again, I am open to any name selections here.
> > 
> > Only static functions have suffixes. In my opinion, explicitly marking static
> > might be a little clearer.
> > kallsyms_lookup_static_name()
> > kallsyms_on_each_match_static_symbol()

But this is not correctly check the symbol is static or not. If you
check the symbol is really static, it is OK. (return NULL if the symbol
is global.)

Thank you,

> 
> While these names are shorter, I think they are more confusing. Not all
> folks know that only static functions can have suffixes. 
> 
> Maybe we should not hide the "try match full name first first" in the
> API, and let the users handle it. Then, we can safely call the new APIs
> *_without_suffix(), as Masami suggested. 
> 
> If there is no objections, I will send v2 based on this direction. 
> 
> Thanks,
> Song
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  parent reply	other threads:[~2024-08-02 13:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-30  0:54 [PATCH 0/3] Fix kallsyms with CONFIG_LTO_CLANG Song Liu
2024-07-30  0:54 ` [PATCH 1/3] kallsyms: Do not cleanup .llvm.<hash> suffix before sorting symbols Song Liu
2024-07-30  0:54 ` [PATCH 2/3] kallsyms: Add APIs to match symbol without .llmv.<hash> suffix Song Liu
2024-07-30 13:03   ` Masami Hiramatsu
2024-07-31  1:00     ` Song Liu
2024-08-02  1:18       ` Leizhen (ThunderTown)
2024-08-02  3:45         ` Song Liu
2024-08-02  6:53           ` Leizhen (ThunderTown)
2024-08-02 13:04           ` Masami Hiramatsu [this message]
2024-08-02 15:45       ` Petr Mladek
2024-08-02 17:09         ` Song Liu
2024-08-05 12:53           ` Masami Hiramatsu
2024-08-02 17:16   ` Song Liu
2024-07-30  0:54 ` [PATCH 3/3] tracing/kprobes: Use APIs that matches symbols with .llvm.<hash> suffix Song Liu
2024-07-30 13:04   ` Masami Hiramatsu
2024-07-31  1:09     ` Song Liu
2024-07-30  5:36 ` [PATCH 0/3] Fix kallsyms with CONFIG_LTO_CLANG Song Liu

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=20240802220427.8404fa9081b9a740c4f9cb06@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=justinstitt@google.com \
    --cc=kees@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mcgrof@kernel.org \
    --cc=mmaurer@google.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=samitolvanen@google.com \
    --cc=song@kernel.org \
    --cc=songliubraving@meta.com \
    --cc=thunder.leizhen@huawei.com \
    --cc=thunder.leizhen@huaweicloud.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).