Re: [PATCH] bpf: Mark kfuncs as __noclone

[Yonghong Song <yonghong.song@linux.dev>]

On 8/27/25 12:52 PM, Alan Maguire wrote:
> On 27/08/2025 20:41, Eduard Zingerman wrote:
>> On Wed, 2025-08-27 at 20:28 +0100, Alan Maguire wrote:
>>
>> [...]
>>
>>> I'm working on a small 2-patch series at the moment to improve this. The
>>> problem is we currently have no way to associate the DWARF with the
>>> relevant ELF function; DWARF representations of functions do not have
>>> "." suffixes either so we are just matching by name prefix when we
>>> collect DWARF info about a particular function.
>> Oh, I see, there is no way to associate DWARF info with either
>> 'bpf_strnchr' or 'bpf_strnchr.constprop.0' w/o checking address.
>> Thank you.
>>
>>> The series I'm working on uses DWARF addresses to improve the DWARF/ELF
>>> association, ensuring that we don't toss functions that look
>>> inconsistent but just have .part or .cold suffixed components that have
>>> non-matching DWARF function signatures. ".constprop" isn't covered yet
>>> however.
>> Is ".constprop" special, or just has to be allowed as one of the prefixes?
>>
> Yonghong can remind me if I've got this wrong, but .constprop is
> somewhat different from .part/.cold in that the latter aren't really on

For symbol with .cold, it is not a function. It is just a jump target
from another function.

For symbol with .part, it is a actual function, but mostly like its
function signature has changed as it is part of the original
function.

For symbol with .constprop, is a clone of another function but
with less parameters, i.e., some parameters become a constant
inside the .constprop.<n> function.

With gcc build, you can see even more complicated suffixes:
   ffffffff81825bf0 t __remove_instance.part.0.constprop.0
   ffffffff81ed07c0 t eventfd_ctx_fileget.part.0.isra.0
   ...

> function boundaries. Sometimes we want to retain .constprop
> representations since they are function boundaries and sometimes do not
> mess with parameters in incompatible ways. If we can find a good
> heuristic for tossing them when they are not helpful as in the above
> case that would be great, but I'm not sure how to do that without losing

It is indeed very hard to have a good heuristic for those function
with suffixes. '<func>.constprop.<n>' might be easier as you can
check location in the subprogrm, if there is no location, most
likely that parameter has become a constant inside the function.

Currently I am working on llvm to add
   - function with suffixes
   - function with changed signature and without suffixes.

Such infomation should have better mapping from func to
its type.

> BTF representations which are useful. Any suggestions on that would be
> really great; in the meantime I'll try and get the series dealing with
> .part and .cold functions out ASAP. Thanks!
>
> Alan