Re: [PATCH 2/3] kallsyms: Add APIs to match symbol without .llmv. suffix.

Song Liu
2024-08-02T17:09:18Z

Hi Petr,

> On Aug 2, 2024, at 8:45 AM, Petr Mladek <pmladek@suse.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.

Thanks,
Song