From: Yonghong Song <yonghong.song@linux.dev>
To: Tony Ambardar <tony.ambardar@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Miguel Ojeda <ojeda@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH bpf v2 1/2] compiler_types.h: Define __retain for __attribute__((__retain__))
Date: Fri, 14 Jun 2024 11:47:19 -0700 [thread overview]
Message-ID: <f1459b36-fd78-4ac3-8c37-e34222c546bf@linux.dev> (raw)
In-Reply-To: <ZmeEs2eaRe0E1Hk8@kodidev-ubuntu>
On 6/10/24 3:56 PM, Tony Ambardar wrote:
> On Tue, Jun 04, 2024 at 10:55:39PM -0700, Yonghong Song wrote:
>> On 6/3/24 10:23 PM, Tony Ambardar wrote:
>>> Some code includes the __used macro to prevent functions and data from
>>> being optimized out. This macro implements __attribute__((__used__)), which
>>> operates at the compiler and IR-level, and so still allows a linker to
>>> remove objects intended to be kept.
>>>
>>> Compilers supporting __attribute__((__retain__)) can address this gap by
>>> setting the flag SHF_GNU_RETAIN on the section of a function/variable,
>>> indicating to the linker the object should be retained. This attribute is
>>> available since gcc 11, clang 13, and binutils 2.36.
>>>
>>> Provide a __retain macro implementing __attribute__((__retain__)), whose
>>> first user will be the '__bpf_kfunc' tag.
>>>
>>> Link: https://lore.kernel.org/bpf/ZlmGoT9KiYLZd91S@krava/T/
>>> Cc: stable@vger.kernel.org # v6.6+
>>> Signed-off-by: Tony Ambardar <Tony.Ambardar@gmail.com>
>>> ---
>>> include/linux/compiler_types.h | 23 +++++++++++++++++++++++
>>> 1 file changed, 23 insertions(+)
>>>
>>> diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
>>> index 93600de3800b..f14c275950b5 100644
>>> --- a/include/linux/compiler_types.h
>>> +++ b/include/linux/compiler_types.h
>>> @@ -143,6 +143,29 @@ static inline void __chk_io_ptr(const volatile void __iomem *ptr) { }
>>> # define __preserve_most
>>> #endif
>>> +/*
>>> + * Annotating a function/variable with __retain tells the compiler to place
>>> + * the object in its own section and set the flag SHF_GNU_RETAIN. This flag
>>> + * instructs the linker to retain the object during garbage-cleanup or LTO
>>> + * phases.
>>> + *
>>> + * Note that the __used macro is also used to prevent functions or data
>>> + * being optimized out, but operates at the compiler/IR-level and may still
>>> + * allow unintended removal of objects during linking.
>>> + *
>>> + * Optional: only supported since gcc >= 11, clang >= 13
>>> + *
>>> + * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-retain-function-attribute
>>> + * clang: https://clang.llvm.org/docs/AttributeReference.html#retain
>>> + */
>>> +#if __has_attribute(__retain__) && \
>>> + (defined(CONFIG_LD_DEAD_CODE_DATA_ELIMINATION) || \
>>> + defined(CONFIG_LTO_CLANG))
>> Could you explain why CONFIG_LTO_CLANG is added here?
>> IIUC, the __used macro permits garbage collection at section
>> level, so CLANG_LTO_CLANG without
>> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
>> shuold not change final section dynamics, right?
> Hi Yonghong,
>
> I included the conditional guard to ensure consistent behaviour between
> __retain and other features forcing split sections. In particular, the same
> guard is used in vmlinux.lds.h to merge split sections where needed. For
> example, using __retain in llvm builds without CONFIG_LTO was failing CI
> tests on kernel-patches/bpf because the kernel didn't boot properly. And in
> further testing, the kernel had no issues loading BPF kfunc modules with
> such split sections, so I left the module (partial) linking scripts alone.
I tried with both bpf and bpf-next tree and I cannot make CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y
in .config file. The following are all occurances in Kconfig:
$ egrep -r HAVE_LD_DEAD_CODE_DATA_ELIMINATION
arch/mips/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
arch/powerpc/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if HAVE_OBJTOOL_MCOUNT && (!ARCH_USING_PATCHABLE_FUNCTION_ENTRY || (!CC_IS_GCC || GCC_VERSION >= 110100))
arch/riscv/Kconfig: select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
init/Kconfig:config HAVE_LD_DEAD_CODE_DATA_ELIMINATION
init/Kconfig: depends on HAVE_LD_DEAD_CODE_DATA_ELIMINATION
Are there some pending patches to enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
for x86?
I could foce CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y with the following hack:
diff --git a/init/Kconfig b/init/Kconfig
index 72404c1f2157..adf8718e2f5b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1402,7 +1402,7 @@ config CC_OPTIMIZE_FOR_SIZE
endchoice
config HAVE_LD_DEAD_CODE_DATA_ELIMINATION
- bool
+ def_bool y
help
This requires that the arch annotates or otherwise protects
its external entry points from being discarded. Linker scripts
But with the above, I cannot boot the kernel.
Did I miss anything?
>
> Maybe I misunderstand you question re: __used?
>
> Thanks,
> Tony
>>> +# define __retain __attribute__((__retain__))
>>> +#else
>>> +# define __retain
>>> +#endif
>>> +
>>> /* Compiler specific macros. */
>>> #ifdef __clang__
>>> #include <linux/compiler-clang.h>
next prev parent reply other threads:[~2024-06-14 18:47 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-31 1:30 Problem with BTF generation on mips64el Tony Ambardar
2024-05-31 2:17 ` Hengqi Chen
2024-05-31 8:13 ` Jiri Olsa
2024-05-31 11:36 ` Tony Ambardar
2024-05-31 14:21 ` Jiri Olsa
2024-06-03 9:02 ` Tony Ambardar
2024-06-03 9:18 ` Jiri Olsa
2024-06-03 12:16 ` [PATCH bpf v1 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-03 12:16 ` [PATCH bpf v1 1/2] Compiler Attributes: Add __retain macro Tony Ambardar
2024-06-03 13:57 ` Miguel Ojeda
2024-06-04 2:37 ` Tony Ambardar
2024-06-03 12:16 ` [PATCH bpf v1 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04 5:23 ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs Tony Ambardar
2024-06-04 5:23 ` [PATCH bpf v2 1/2] compiler_types.h: Define __retain for __attribute__((__retain__)) Tony Ambardar
2024-06-05 5:55 ` Yonghong Song
2024-06-10 22:56 ` Tony Ambardar
2024-06-14 18:47 ` Yonghong Song [this message]
2024-06-15 6:57 ` Tony Ambardar
2024-06-17 3:26 ` Yonghong Song
2024-06-04 5:23 ` [PATCH bpf v2 2/2] bpf: Harden __bpf_kfunc tag against linker kfunc removal Tony Ambardar
2024-06-04 7:56 ` Jiri Olsa
2024-06-25 10:46 ` Geert Uytterhoeven
2024-06-26 9:52 ` Jiri Olsa
2024-06-26 11:40 ` Geert Uytterhoeven
2024-06-14 17:20 ` [PATCH bpf v2 0/2] bpf: Fix linker optimization removing kfuncs patchwork-bot+netdevbpf
2024-05-31 10:49 ` Problem with BTF generation on mips64el Tony Ambardar
2024-05-31 16:06 ` Arnaldo Carvalho de Melo
2024-05-31 21:46 ` Tony Ambardar
2024-06-03 11:20 ` Tony Ambardar
2024-06-03 14:56 ` Arnaldo Carvalho de Melo
2024-06-03 17:40 ` elfutils DWARF problem was: " Arnaldo Carvalho de Melo
2024-06-03 19:18 ` Mark Wielaard
2024-06-04 3:47 ` Tony Ambardar
2024-06-04 8:27 ` Ying Huang
2024-06-11 6:36 ` Tony Ambardar
2024-06-11 7:51 ` Tony Ambardar
2024-06-11 13:07 ` Mark Wielaard
2024-06-12 0:18 ` Tony Ambardar
2024-06-12 3:31 ` Ying Huang
2024-06-12 2:39 ` Ying Huang
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=f1459b36-fd78-4ac3-8c37-e34222c546bf@linux.dev \
--to=yonghong.song@linux.dev \
--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=martin.lau@linux.dev \
--cc=ojeda@kernel.org \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tony.ambardar@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.