linux-kernel - Re: [PATCH] bpf: Mark kfuncs as _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45c49b4eedc6038d350f61572e5eed9f183b781b.camel@gmail.com>
Date: Tue, 26 Aug 2025 22:02:31 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Yonghong Song <yonghong.song@...ux.dev>, Andrea Righi
 <arighi@...dia.com>,  Alexei Starovoitov	 <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Andrii Nakryiko	 <andrii@...nel.org>
Cc: Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>, 
 John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
 Stanislav Fomichev <sdf@...ichev.me>,  Hao Luo <haoluo@...gle.com>, Jiri
 Olsa <jolsa@...nel.org>, David Vernet <void@...ifault.com>, 
	bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Mark kfuncs as __noclone

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?

[...]