Re: [PATCH] bpf: Mark kfuncs as __noclone

[Andrea Righi <arighi@nvidia.com>]

On Tue, Aug 26, 2025 at 10:02:31PM -0700, Eduard Zingerman wrote:
> On Tue, 2025-08-26 at 13:17 -0700, Yonghong Song wrote:
> 
> [...]
> 
> > I tried with gcc14 and can reproduced the issue described in the above.
> > I build the kernel like below with gcc14
> >    make KCFLAGS='-O3' -j
> > and get the following build error
> >    WARN: resolve_btfids: unresolved symbol bpf_strnchr
> >    make[2]: *** [/home/yhs/work/bpf-next/scripts/Makefile.vmlinux:91: vmlinux] Error 255
> >    make[2]: *** Deleting file 'vmlinux'
> > Checking the symbol table:
> >     22276: ffffffff81b15260   249 FUNC    LOCAL  DEFAULT    1 bpf_strnchr.cons[...]
> >    235128: ffffffff81b1f540   296 FUNC    GLOBAL DEFAULT    1 bpf_strnchr
> > and the disasm code:
> >    bpf_strnchr:
> >      ...
> > 
> >    bpf_strchr:
> >      ...
> >      bpf_strnchr.constprop.0
> >      ...
> > 
> > So in symbol table, we have both bpf_strnchr.constprop.0 and bpf_strnchr.
> > For such case, pahole will skip func bpf_strnchr hence the above resolve_btfids
> > failure.
> > 
> > The solution in this patch can indeed resolve this issue.
> 
> It looks like instead of adding __noclone there is an option to
> improve pahole's filtering of ambiguous functions.
> Abstractly, there is nothing wrong with having a clone of a global
> function that has undergone additional optimizations. As long as the
> original symbol exists, everything should be fine.
> 
> Since kfuncs are global, this should guarantee that the compiler does not
> change their signature, correct? Does this also hold for LTO builds?
> If so, when pahole sees a set of symbols like [foo, foo.1, foo.2, ...],
> with 'foo' being global and the rest local, then there is no real need
> to filter out 'foo'.
> 
> Wdyt?

I think we should do both: fix resolve_btfids to ignore compiler
optimization suffixes (.isra., .constprop., .part., .cold, ...) and add
__noclone.

This feels like the safest path IMHO. Fixing resolve_btfids alone works
with current compilers, but future compiler versions, under aggressive
IPA/LTO optimizations, might decide that the main global symbol is
redundant and drop it altogether, leading to similar issues.

Basically, fixing the tool makes the BTF pipeline more robust, adding
__noclone also makes the exported symbols themselves more robust,
regardless of compiler optimizations.

Thanks,
-Andrea