From: Andrea Righi <arighi@nvidia.com>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Yonghong Song <yonghong.song@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, David Vernet <void@manifault.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] bpf: Mark kfuncs as __noclone
Date: Wed, 27 Aug 2025 09:45:15 +0200 [thread overview]
Message-ID: <aK63i7yvJFKkcDpw@gpd4> (raw)
In-Reply-To: <afd8091d11429e63949a16fc24228078b08c7726.camel@gmail.com>
On Wed, Aug 27, 2025 at 12:01:09AM -0700, Eduard Zingerman wrote:
> On Tue, 2025-08-26 at 23:52 -0700, Eduard Zingerman wrote:
>
> [...]
>
> > If we are being really paranoid about LTO builds, is __noclone sufficient?
> > E.g. [1] does not imply that signature can't be changed.
> > We currently apply only __retain__, here is a little test with both attributes:
>
> Nope, there are also 'used' and 'noinline' applied.
> With these the function is preserved as expected.
> Sorry for the noise.
Yeah, 'used' forces the function to be emitted even if it appears
unreferenced. Together with 'noclone', 'retain' and 'noinline', should
ensure the symbol exists and can be reliably found by resolve_btfids.
We could be extra paranoid and mimic EXPORT_SYMBOL(), moving the symbols to
their own section, but in practice I don't think this is strictly
necessary, even in presence of aggressive compiler / LTO optimizations.
Thanks,
-Andrea
next prev parent reply other threads:[~2025-08-27 7:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 14:05 [PATCH] bpf: Mark kfuncs as __noclone Andrea Righi
2025-08-26 20:17 ` Yonghong Song
2025-08-27 5:02 ` Eduard Zingerman
2025-08-27 5:41 ` Andrea Righi
2025-08-27 6:52 ` Eduard Zingerman
2025-08-27 7:01 ` Eduard Zingerman
2025-08-27 7:45 ` Andrea Righi [this message]
2025-08-27 17:03 ` Yonghong Song
2025-08-27 17:00 ` Yonghong Song
2025-08-27 19:13 ` Eduard Zingerman
2025-08-27 19:28 ` Alan Maguire
2025-08-27 19:41 ` Eduard Zingerman
2025-08-27 19:52 ` Alan Maguire
2025-08-27 22:28 ` Yonghong Song
2025-08-27 22:10 ` Yonghong Song
2025-08-27 2:10 ` David Vernet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aK63i7yvJFKkcDpw@gpd4 \
--to=arighi@nvidia.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=void@manifault.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).