All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH v2 3/3] tracing/kprobes: Use APIs that matches symbols without .XXX suffix
Date: Wed, 7 Aug 2024 09:01:46 +0900	[thread overview]
Message-ID: <20240807090146.88b38c2fbd1cd8db683be22c@kernel.org> (raw)
In-Reply-To: <6F6AC75C-89F9-45C3-98FF-07AD73C38078@fb.com>

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. 

Thanks,

> 
> Thanks,
> Song
> 
> 
> 


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

  reply	other threads:[~2024-08-07  0:02 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 [this message]
2024-08-07  0:19               ` Song Liu
2024-08-07 10:08                 ` Masami Hiramatsu
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=20240807090146.88b38c2fbd1cd8db683be22c@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.