From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Song Liu <songliubraving@meta.com>
Cc: Steven Rostedt <rostedt@goodmis.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>
Subject: Re: [PATCH v2 3/3] tracing/kprobes: Use APIs that matches symbols without .XXX suffix
Date: Wed, 7 Aug 2024 19:08:09 +0900 [thread overview]
Message-ID: <20240807190809.cd316e7f813400a209aae72a@kernel.org> (raw)
In-Reply-To: <BEEE3F89-717B-44A4-8571-68DA69408DA4@fb.com>
On Wed, 7 Aug 2024 00:19:20 +0000
Song Liu <songliubraving@meta.com> wrote:
>
>
> > On Aug 6, 2024, at 5:01 PM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >
> > On Tue, 6 Aug 2024 20:12:55 +0000
> > Song Liu <songliubraving@meta.com> wrote:
> >
> >>
> >>
> >>> On Aug 6, 2024, at 1:01 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >>>
> >>> On Tue, 6 Aug 2024 16:00:49 -0400
> >>> Steven Rostedt <rostedt@goodmis.org> wrote:
> >>>
> >>>>>>> + if (IS_ENABLED(CONFIG_LTO_CLANG) && !addr)
> >>>>>>> + addr = kallsyms_lookup_name_without_suffix(trace_kprobe_symbol(tk));
> >>>>>>> +
> >>>>>>
> >>>>>> So you do the lookup twice if this is enabled?
> >>>>>>
> >>>>>> Why not just use "kallsyms_lookup_name_without_suffix()" the entire time,
> >>>>>> and it should work just the same as "kallsyms_lookup_name()" if it's not
> >>>>>> needed?
> >>>>>
> >>>>> We still want to give priority to full match. For example, we have:
> >>>>>
> >>>>> [root@~]# grep c_next /proc/kallsyms
> >>>>> ffffffff81419dc0 t c_next.llvm.7567888411731313343
> >>>>> ffffffff81680600 t c_next
> >>>>> ffffffff81854380 t c_next.llvm.14337844803752139461
> >>>>>
> >>>>> If the goal is to explicitly trace c_next.llvm.7567888411731313343, the
> >>>>> user can provide the full name. If we always match _without_suffix, all
> >>>>> of the 3 will match to the first one.
> >>>>>
> >>>>> Does this make sense?
> >>>>
> >>>> Yes. Sorry, I missed the "&& !addr)" after the "IS_ENABLED()", which looked
> >>>> like you did the command twice.
> >>>
> >>> But that said, does this only have to be for llvm? Or should we do this for
> >>> even gcc? As I believe gcc can give strange symbols too.
> >>
> >> I think most of the issue comes with LTO, as LTO promotes local static
> >> functions to global functions. IIUC, we don't have GCC built, LTO enabled
> >> kernel yet.
> >>
> >> In my GCC built, we have suffixes like ".constprop.0", ".part.0", ".isra.0",
> >> and ".isra.0.cold". We didn't do anything about these before this set. So I
> >> think we are OK not handling them now. We sure can enable it for GCC built
> >> kernel in the future.
> >
> > Hmm, I think it should be handled as it is. This means it should do as
> > livepatch does. Since I expected user will check kallsyms if gets error,
> > we should keep this as it is. (if a symbol has suffix, it should accept
> > symbol with suffix, or user will get confused because they can not find
> > which symbol is kprobed.)
> >
> > Sorry about the conclusion (so I NAK this), but this is a good discussion.
>
> Do you mean we do not want patch 3/3, but would like to keep 1/3 and part
> of 2/3 (remove the _without_suffix APIs)? If this is the case, we are
> undoing the change by Sami in [1], and thus may break some tracing tools.
What tracing tools may be broke and why?
For this suffix problem, I would like to add another patch to allow probing on
suffixed symbols. (It seems suffixed symbols are not available at this point)
The problem is that the suffixed symbols maybe a "part" of the original function,
thus user has to carefully use it.
>
> Sami, could you please share your thoughts on this?
Sami, I would like to know what problem you have on kprobes.
Thank you,
>
> If this works, I will send next version with 1/3 and part of 2/3.
>
> Thanks,
> Song
>
> [1] https://lore.kernel.org/all/20210408182843.1754385-8-samitolvanen@google.com/
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2024-08-07 10:08 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-02 21:08 [PATCH v2 0/3] Fix kallsyms with CONFIG_LTO_CLANG Song Liu
2024-08-02 21:08 ` [PATCH v2 1/3] kallsyms: Do not cleanup .llvm.<hash> suffix before sorting symbols Song Liu
2024-08-02 21:08 ` [PATCH v2 2/3] kallsyms: Add APIs to match symbol without .XXXX suffix Song Liu
2024-08-05 13:45 ` Masami Hiramatsu
2024-08-05 17:46 ` Song Liu
2024-08-08 10:20 ` Petr Mladek
2024-08-08 15:13 ` Song Liu
2024-08-02 21:08 ` [PATCH v2 3/3] tracing/kprobes: Use APIs that matches symbols without .XXX suffix Song Liu
2024-08-06 18:44 ` Steven Rostedt
2024-08-06 19:35 ` Song Liu
2024-08-06 20:00 ` Steven Rostedt
2024-08-06 20:01 ` Steven Rostedt
2024-08-06 20:12 ` Song Liu
2024-08-07 0:01 ` Masami Hiramatsu
2024-08-07 0:19 ` Song Liu
2024-08-07 10:08 ` Masami Hiramatsu [this message]
2024-08-07 15:33 ` Sami Tolvanen
2024-08-07 20:48 ` Song Liu
2024-08-08 9:59 ` Petr Mladek
2024-08-08 15:20 ` Song Liu
2024-08-09 15:40 ` Petr Mladek
2024-08-09 16:33 ` Song Liu
2024-08-08 15:52 ` Masami Hiramatsu
2024-08-09 6:20 ` Alessandro Carminati
2024-08-09 16:40 ` Song Liu
2024-08-07 21:26 ` Masami Hiramatsu
2024-08-07 19:41 ` Song Liu
2024-08-07 20:08 ` Steven Rostedt
2024-08-07 20:40 ` Song Liu
2024-08-07 20:43 ` Song Liu
2024-08-07 20:55 ` Masami Hiramatsu
2024-08-07 21:07 ` Song Liu
2024-08-07 14:58 ` zhang warden
2024-08-07 19:46 ` Song Liu
2024-08-08 2:10 ` zhang warden
2024-08-08 9:48 ` Petr Mladek
2024-08-08 15:17 ` 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=20240807190809.cd316e7f813400a209aae72a@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 \
/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.