Re: Question: fentry on kernel func optimized by compiler

[Alan Maguire <alan.maguire@oracle.com>]

On 28/03/2025 17:21, Andrii Nakryiko wrote:
> On Thu, Mar 27, 2025 at 9:03 AM Tao Chen <chen.dylane@linux.dev> wrote:
>>
>> Hi,
>>
>> I recently encountered a problem when using fentry to trace kernel
>> functions optimized by compiler, the specific situation is as follows:
>> https://github.com/bpftrace/bpftrace/issues/3940
>>
>> Simply put, some functions have been optimized by the compiler. The
>> original function names are found through BTF, but the optimized
>> functions are the ones that exist in kallsyms_lookup_name. Therefore,
>> the two do not match.
>>
>>          func_proto = btf_type_by_id(desc_btf, func->type);
>>          if (!func_proto || !btf_type_is_func_proto(func_proto)) {
>>                  verbose(env, "kernel function btf_id %u does not have a
>> valid func_proto\n",
>>                          func_id);
>>                  return -EINVAL;
>>          }
>>
>>          func_name = btf_name_by_offset(desc_btf, func->name_off);
>>          addr = kallsyms_lookup_name(func_name);
>>          if (!addr) {
>>                  verbose(env, "cannot find address for kernel function
>> %s\n",
>>                          func_name);
>>                  return -EINVAL;
>>          }
>>
>> I have made a simple statistics and there are approximately more than
>> 2,000 functions in Ubuntu 24.04.
>>
>> dylane@2404:~$ cat /proc/kallsyms | grep isra | wc -l
>> 2324
>>
>> So can we add a judgment from libbpf. If it is an optimized function,
> 
> No, we cannot. It's a different function at that point and libbpf
> isn't going to be in the business of guessing on behalf of the user
> whether it's ok to do or not.
> 
> But the user can use multi-kprobe with `prefix*` naming, if they
> encountered (or are anticipating) this situation and think it's fine
> for them.
> 
> As for fentry/fexit, you need to have the correct BTF ID associated
> with that function anyways, so I'm not sure that currently you can
> attach fentry/fexit to such compiler-optimized functions at all
> (pahole won't produce BTF for such functions, right?).
> 

Yep, BTF will not be there for all cases, but ever since we've had the
"optimized_func" BTF feature, we've have encoded BTF for suffixed
functions as long as their parameters are not optimized away and as long
as we don't have multiple inconsistent representations associated with a
function (say two differing function signatures for the same name).
Optimization away of parameters happens quite frequently, but not always
for .isra.0 functions so they are potentially sometimes safe for fentry.

The complication here is that - by design - the function name in BTF
will be the prefix; i.e. "foo" not "foo.isra.0". So how we match up the
BTF with the right suffixed function is an issue; a single function
prefix can have ".isra.0" and ".cold.0" suffixes associated for example.
The latter isn't really a function entry point (in the C code at least);
it's just a split of the function into common path and less common path
for better code locality for the more commonly-executed code.

Yonghong and I talked about this a bit last year in Plumbers, but it did
occur to me that there are conditions where we could match up the prefix
from BTF with a guaranteed fentry point for the function using info we
have today.

/sys/kernel/tracing/available_filter_functions_addr has similar info to
/proc/kallysyms but as far as I understand it we are also guaranteed
that the associated addresses correspond to real function entry points.
So because the BTF representation currently ensures consistency _and_
available function parameters, I think we could use
available_filter_functions_addr to carry out the match and provide the
right function address for the BTF representation.

In the future, the hope is we can handle inconsistent representations
too in BTF, but the above represents a possible approach we could
implement today I think, though I may be missing something. Thanks!

Alan