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 for Android: free password hash cracker in your pocket

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

Message-ID: <0d5c5cf8e1f3efb35b1f597dae2ae2bf0fb9a346.camel@gmail.com>
Date: Wed, 27 Aug 2025 12:41:15 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Alan Maguire <alan.maguire@...cle.com>, 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 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?

[...]