Message-Id: <20240805215340.1e647b9bb1f35af6bd4b909c@kernel.org>
Date: Mon, 5 Aug 2024 21:53:40 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Song Liu <songliubraving@...a.com>
Cc: Petr Mladek <pmladek@...e.com>, Masami Hiramatsu <mhiramat@...nel.org>,
 Song Liu <song@...nel.org>, "live-patching@...r.kernel.org"
 <live-patching@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
 "linux-trace-kernel@...r.kernel.org" <linux-trace-kernel@...r.kernel.org>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Jiri Kosina <jikos@...nel.org>,
 Miroslav Benes <mbenes@...e.cz>, Joe Lawrence <joe.lawrence@...hat.com>,
 Nathan Chancellor <nathan@...nel.org>, "morbo@...gle.com"
 <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, Luis Chamberlain
 <mcgrof@...nel.org>, Leizhen <thunder.leizhen@...wei.com>,
 "kees@...nel.org" <kees@...nel.org>, Kernel Team <kernel-team@...a.com>,
 Matthew Maurer <mmaurer@...gle.com>, Sami Tolvanen
 <samitolvanen@...gle.com>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without
 .llmv.<hash> suffix.

On Fri, 2 Aug 2024 17:09:12 +0000
Song Liu <songliubraving@...a.com> wrote:

> Hi Petr, 
> 
> > On Aug 2, 2024, at 8:45 AM, Petr Mladek <pmladek@...e.com> wrote:
> 
> [...]
> 
> > 
> > IMHO, it depends on the use case. Let's keep "ping_table/"
> > as an example. Why people would want to trace this function?
> > There might be various reasons, for example:
> > 
> >  1. ping_table.llvm.15394922576589127018 appeared in a backtrace
> > 
> >  2. ping_table.llvm.15394922576589127018 appeared in a histogram
> > 
> >  3. ping_table looks interesting when reading code sources
> > 
> >  4. ping_table need to be monitored on all systems because
> >     of security/performance.
> > 
> > The full name "ping_table.llvm.15394922576589127018" is perfectly
> > fine in the 1st and 2nd scenario. People knew this name already
> > before they start thinking about tracing.
> > 
> > The short name is more practical in 3rd and 4th scenario. Especially,
> > when there is only one static symbol with this short name. Otherwise,
> > the user would need an extra step to find the full name.
> > 
> > The full name is even more problematic for system monitors. These
> > applications might need to probe particular symbols. They might
> > have hard times when the symbol is:
> > 
> >    <symbol_name_from_sources>.<random_suffix_generated_by_compiler>
> > 
> > They will have to deal with it. But it means that every such tool
> > would need an extra (non-trivial) code for this. Every tool would
> > try its own approach => a lot of problems.
> > 
> > IMHO, the two APIs could make the life easier.
> > 
> > Well, even kprobe might need two APIs to allow probing by
> > full name or without the suffix.
> 
> The problem is, with potential partial inlining by modern compilers, 
> tracing "symbol name from sources" is not accurate. In our production 
> kernels, we have to add some explicit "noline" to make sure we can 
> trace these functions reliably. 
> 
> Of course, this issue exists without random suffix: any function 
> could be partially inlined. However, allowing tracing without the 
> suffix seems to hint that tracing with "symbol name from sources" 
> is valid, which is not really true. 
> 
> At the moment, I have no objections to keep the _without_suffix
> APIs. But for long term, I still think we need to set clear 
> expectations for the users: tracing symbols from sources is not
> reliable. 

OK, I understand this part. I agree the problem. Even if the symbol
is unique on kallsyms (without suffix), it may have a suffix and is
not correct function entry.

I think to solve this issue, we need a better DWARF, or add a symbol
suffix like;

https://lkml.org/lkml/2023/12/4/1535

Thank you,

> 
> Thanks,
> Song
> 


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

Powered by blists - more mailing lists