[PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

Weak external linkage is intended for cases where a symbol reference
can remain unsatisfied in the final link. Taking the address of such a
symbol should yield NULL if the reference was not satisfied.

Given that ordinary RIP or PC relative references cannot produce NULL,
some kind of indirection is always needed in such cases, and in position
independent code, this results in a GOT entry. In ordinary code, it is
arch specific but amounts to the same thing.

While unavoidable in some cases, weak references are currently also used
to declare symbols that are always defined in the final link, but not in
the first linker pass. This means we end up with worse codegen for no
good reason. So let's clean this up, by providing preliminary
definitions that are only used as a fallback.

Changes since v3:
- drop unnecessary preliminary definitions for BTF start/stop
- add Jiri's ack

Changes since v2:
- fix build issue in patch #3 reported by Jiri
- add Arnd's acks

Changes since v1:
- update second occurrence of BTF start/end markers
- drop NULL check of __start_BTF[] which is no longer meaningful
- avoid the preliminary BTF symbols if CONFIG_DEBUG_INFO_BTF is not set
- add Andrii's ack to patch #3
- patches #1 and #2 unchanged

Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Martin KaFai Lau <martin.lau@linux.dev>
Cc: linux-arch@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Jiri Olsa <olsajiri@gmail.com>

Ard Biesheuvel (3):
  kallsyms: Avoid weak references for kallsyms symbols
  vmlinux: Avoid weak reference to notes section
  btf: Avoid weak external references

 include/asm-generic/vmlinux.lds.h | 19 +++++++++++++
 kernel/bpf/btf.c                  |  7 +++--
 kernel/bpf/sysfs_btf.c            |  6 ++--
 kernel/kallsyms.c                 |  6 ----
 kernel/kallsyms_internal.h        | 30 ++++++++------------
 kernel/ksysfs.c                   |  4 +--
 lib/buildid.c                     |  4 +--
 7 files changed, 43 insertions(+), 33 deletions(-)

-- 
2.44.0.683.g7961c838ac-goog

[PATCH v4 1/3] kallsyms: Avoid weak references for kallsyms symbols

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

kallsyms is a directory of all the symbols in the vmlinux binary, and so
creating it is somewhat of a chicken-and-egg problem, as its non-zero
size affects the layout of the binary, and therefore the values of the
symbols.

For this reason, the kernel is linked more than once, and the first pass
does not include any kallsyms data at all. For the linker to accept
this, the symbol declarations describing the kallsyms metadata are
emitted as having weak linkage, so they can remain unsatisfied. During
the subsequent passes, the weak references are satisfied by the kallsyms
metadata that was constructed based on information gathered from the
preceding passes.

Weak references lead to somewhat worse codegen, because taking their
address may need to produce NULL (if the reference was unsatisfied), and
this is not usually supported by RIP or PC relative symbol references.

Given that these references are ultimately always satisfied in the final
link, let's drop the weak annotation, and instead, provide fallback
definitions in the linker script that are only emitted if an unsatisfied
reference exists.

While at it, drop the FRV specific annotation that these symbols reside
in .rodata - FRV is long gone.

Tested-by: Nick Desaulniers <ndesaulniers@google.com> # Boot
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lkml.kernel.org/r/20230504174320.3930345-1-ardb%40kernel.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 include/asm-generic/vmlinux.lds.h | 19 +++++++++++++
 kernel/kallsyms.c                 |  6 ----
 kernel/kallsyms_internal.h        | 30 ++++++++------------
 3 files changed, 31 insertions(+), 24 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index f7749d0f2562..e8449be62058 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -448,11 +448,30 @@
 #endif
 #endif
 
+/*
+ * Some symbol definitions will not exist yet during the first pass of the
+ * link, but are guaranteed to exist in the final link. Provide preliminary
+ * definitions that will be superseded in the final link to avoid having to
+ * rely on weak external linkage, which requires a GOT when used in position
+ * independent code.
+ */
+#define PRELIMINARY_SYMBOL_DEFINITIONS					\
+	PROVIDE(kallsyms_addresses = .);				\
+	PROVIDE(kallsyms_offsets = .);					\
+	PROVIDE(kallsyms_names = .);					\
+	PROVIDE(kallsyms_num_syms = .);					\
+	PROVIDE(kallsyms_relative_base = .);				\
+	PROVIDE(kallsyms_token_table = .);				\
+	PROVIDE(kallsyms_token_index = .);				\
+	PROVIDE(kallsyms_markers = .);					\
+	PROVIDE(kallsyms_seqs_of_names = .);
+
 /*
  * Read only Data
  */
 #define RO_DATA(align)							\
 	. = ALIGN((align));						\
+	PRELIMINARY_SYMBOL_DEFINITIONS					\
 	.rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {		\
 		__start_rodata = .;					\
 		*(.rodata) *(.rodata.*)					\
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 18edd57b5fe8..22ea19a36e6e 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -325,12 +325,6 @@ static unsigned long get_symbol_pos(unsigned long addr,
 	unsigned long symbol_start = 0, symbol_end = 0;
 	unsigned long i, low, high, mid;
 
-	/* This kernel should never had been booted. */
-	if (!IS_ENABLED(CONFIG_KALLSYMS_BASE_RELATIVE))
-		BUG_ON(!kallsyms_addresses);
-	else
-		BUG_ON(!kallsyms_offsets);
-
 	/* Do a binary search on the sorted kallsyms_addresses array. */
 	low = 0;
 	high = kallsyms_num_syms;
diff --git a/kernel/kallsyms_internal.h b/kernel/kallsyms_internal.h
index 27fabdcc40f5..85480274fc8f 100644
--- a/kernel/kallsyms_internal.h
+++ b/kernel/kallsyms_internal.h
@@ -5,27 +5,21 @@
 #include <linux/types.h>
 
 /*
- * These will be re-linked against their real values
- * during the second link stage.
+ * These will be re-linked against their real values during the second link
+ * stage. Preliminary values must be provided in the linker script using the
+ * PROVIDE() directive so that the first link stage can complete successfully.
  */
-extern const unsigned long kallsyms_addresses[] __weak;
-extern const int kallsyms_offsets[] __weak;
-extern const u8 kallsyms_names[] __weak;
+extern const unsigned long kallsyms_addresses[];
+extern const int kallsyms_offsets[];
+extern const u8 kallsyms_names[];
 
-/*
- * Tell the compiler that the count isn't in the small data section if the arch
- * has one (eg: FRV).
- */
-extern const unsigned int kallsyms_num_syms
-__section(".rodata") __attribute__((weak));
-
-extern const unsigned long kallsyms_relative_base
-__section(".rodata") __attribute__((weak));
+extern const unsigned int kallsyms_num_syms;
+extern const unsigned long kallsyms_relative_base;
 
-extern const char kallsyms_token_table[] __weak;
-extern const u16 kallsyms_token_index[] __weak;
+extern const char kallsyms_token_table[];
+extern const u16 kallsyms_token_index[];
 
-extern const unsigned int kallsyms_markers[] __weak;
-extern const u8 kallsyms_seqs_of_names[] __weak;
+extern const unsigned int kallsyms_markers[];
+extern const u8 kallsyms_seqs_of_names[];
 
 #endif // LINUX_KALLSYMS_INTERNAL_H_
-- 
2.44.0.683.g7961c838ac-goog

Re: [PATCH v4 1/3] kallsyms: Avoid weak references for kallsyms symbols

[Masahiro Yamada]

On Tue, Apr 16, 2024 at 1:20 AM Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> kallsyms is a directory of all the symbols in the vmlinux binary, and so
> creating it is somewhat of a chicken-and-egg problem, as its non-zero
> size affects the layout of the binary, and therefore the values of the
> symbols.
>
> For this reason, the kernel is linked more than once, and the first pass
> does not include any kallsyms data at all. For the linker to accept
> this, the symbol declarations describing the kallsyms metadata are
> emitted as having weak linkage, so they can remain unsatisfied. During
> the subsequent passes, the weak references are satisfied by the kallsyms
> metadata that was constructed based on information gathered from the
> preceding passes.
>
> Weak references lead to somewhat worse codegen, because taking their
> address may need to produce NULL (if the reference was unsatisfied), and
> this is not usually supported by RIP or PC relative symbol references.
>
> Given that these references are ultimately always satisfied in the final
> link, let's drop the weak annotation, and instead, provide fallback
> definitions in the linker script that are only emitted if an unsatisfied
> reference exists.
>
> While at it, drop the FRV specific annotation that these symbols reside
> in .rodata - FRV is long gone.
>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # Boot
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Link: https://lkml.kernel.org/r/20230504174320.3930345-1-ardb%40kernel.org
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---


I dropped v5, and picked up this one.

Thanks.



>  include/asm-generic/vmlinux.lds.h | 19 +++++++++++++
>  kernel/kallsyms.c                 |  6 ----
>  kernel/kallsyms_internal.h        | 30 ++++++++------------
>  3 files changed, 31 insertions(+), 24 deletions(-)
>
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index f7749d0f2562..e8449be62058 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -448,11 +448,30 @@
>  #endif
>  #endif
>
> +/*
> + * Some symbol definitions will not exist yet during the first pass of the
> + * link, but are guaranteed to exist in the final link. Provide preliminary
> + * definitions that will be superseded in the final link to avoid having to
> + * rely on weak external linkage, which requires a GOT when used in position
> + * independent code.
> + */
> +#define PRELIMINARY_SYMBOL_DEFINITIONS                                 \
> +       PROVIDE(kallsyms_addresses = .);                                \
> +       PROVIDE(kallsyms_offsets = .);                                  \
> +       PROVIDE(kallsyms_names = .);                                    \
> +       PROVIDE(kallsyms_num_syms = .);                                 \
> +       PROVIDE(kallsyms_relative_base = .);                            \
> +       PROVIDE(kallsyms_token_table = .);                              \
> +       PROVIDE(kallsyms_token_index = .);                              \
> +       PROVIDE(kallsyms_markers = .);                                  \
> +       PROVIDE(kallsyms_seqs_of_names = .);
> +
>  /*
>   * Read only Data
>   */
>  #define RO_DATA(align)                                                 \
>         . = ALIGN((align));                                             \
> +       PRELIMINARY_SYMBOL_DEFINITIONS                                  \
>         .rodata           : AT(ADDR(.rodata) - LOAD_OFFSET) {           \
>                 __start_rodata = .;                                     \
>                 *(.rodata) *(.rodata.*)                                 \
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index 18edd57b5fe8..22ea19a36e6e 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -325,12 +325,6 @@ static unsigned long get_symbol_pos(unsigned long addr,
>         unsigned long symbol_start = 0, symbol_end = 0;
>         unsigned long i, low, high, mid;
>
> -       /* This kernel should never had been booted. */
> -       if (!IS_ENABLED(CONFIG_KALLSYMS_BASE_RELATIVE))
> -               BUG_ON(!kallsyms_addresses);
> -       else
> -               BUG_ON(!kallsyms_offsets);
> -
>         /* Do a binary search on the sorted kallsyms_addresses array. */
>         low = 0;
>         high = kallsyms_num_syms;
> diff --git a/kernel/kallsyms_internal.h b/kernel/kallsyms_internal.h
> index 27fabdcc40f5..85480274fc8f 100644
> --- a/kernel/kallsyms_internal.h
> +++ b/kernel/kallsyms_internal.h
> @@ -5,27 +5,21 @@
>  #include <linux/types.h>
>
>  /*
> - * These will be re-linked against their real values
> - * during the second link stage.
> + * These will be re-linked against their real values during the second link
> + * stage. Preliminary values must be provided in the linker script using the
> + * PROVIDE() directive so that the first link stage can complete successfully.
>   */
> -extern const unsigned long kallsyms_addresses[] __weak;
> -extern const int kallsyms_offsets[] __weak;
> -extern const u8 kallsyms_names[] __weak;
> +extern const unsigned long kallsyms_addresses[];
> +extern const int kallsyms_offsets[];
> +extern const u8 kallsyms_names[];
>
> -/*
> - * Tell the compiler that the count isn't in the small data section if the arch
> - * has one (eg: FRV).
> - */
> -extern const unsigned int kallsyms_num_syms
> -__section(".rodata") __attribute__((weak));
> -
> -extern const unsigned long kallsyms_relative_base
> -__section(".rodata") __attribute__((weak));
> +extern const unsigned int kallsyms_num_syms;
> +extern const unsigned long kallsyms_relative_base;
>
> -extern const char kallsyms_token_table[] __weak;
> -extern const u16 kallsyms_token_index[] __weak;
> +extern const char kallsyms_token_table[];
> +extern const u16 kallsyms_token_index[];
>
> -extern const unsigned int kallsyms_markers[] __weak;
> -extern const u8 kallsyms_seqs_of_names[] __weak;
> +extern const unsigned int kallsyms_markers[];
> +extern const u8 kallsyms_seqs_of_names[];
>
>  #endif // LINUX_KALLSYMS_INTERNAL_H_
> --
> 2.44.0.683.g7961c838ac-goog
>
>


-- 
Best Regards
Masahiro Yamada

[PATCH v4 2/3] vmlinux: Avoid weak reference to notes section

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

Weak references are references that are permitted to remain unsatisfied
in the final link. This means they cannot be implemented using place
relative relocations, resulting in GOT entries when using position
independent code generation.

The notes section should always exist, so the weak annotations can be
omitted.

Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 kernel/ksysfs.c | 4 ++--
 lib/buildid.c   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index 495b69a71a5d..07fb5987b42b 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -228,8 +228,8 @@ KERNEL_ATTR_RW(rcu_normal);
 /*
  * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
  */
-extern const void __start_notes __weak;
-extern const void __stop_notes __weak;
+extern const void __start_notes;
+extern const void __stop_notes;
 #define	notes_size (&__stop_notes - &__start_notes)
 
 static ssize_t notes_read(struct file *filp, struct kobject *kobj,
diff --git a/lib/buildid.c b/lib/buildid.c
index 898301b49eb6..7954dd92e36c 100644
--- a/lib/buildid.c
+++ b/lib/buildid.c
@@ -182,8 +182,8 @@ unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
  */
 void __init init_vmlinux_build_id(void)
 {
-	extern const void __start_notes __weak;
-	extern const void __stop_notes __weak;
+	extern const void __start_notes;
+	extern const void __stop_notes;
 	unsigned int size = &__stop_notes - &__start_notes;
 
 	build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
-- 
2.44.0.683.g7961c838ac-goog

Re: [PATCH v4 2/3] vmlinux: Avoid weak reference to notes section

[Masahiro Yamada]

On Tue, Apr 16, 2024 at 1:20 AM Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Weak references are references that are permitted to remain unsatisfied
> in the final link. This means they cannot be implemented using place
> relative relocations, resulting in GOT entries when using position
> independent code generation.
>
> The notes section should always exist, so the weak annotations can be
> omitted.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>


Applied to linux-kbuild.
Thanks.




> ---
>  kernel/ksysfs.c | 4 ++--
>  lib/buildid.c   | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
> index 495b69a71a5d..07fb5987b42b 100644
> --- a/kernel/ksysfs.c
> +++ b/kernel/ksysfs.c
> @@ -228,8 +228,8 @@ KERNEL_ATTR_RW(rcu_normal);
>  /*
>   * Make /sys/kernel/notes give the raw contents of our kernel .notes section.
>   */
> -extern const void __start_notes __weak;
> -extern const void __stop_notes __weak;
> +extern const void __start_notes;
> +extern const void __stop_notes;
>  #define        notes_size (&__stop_notes - &__start_notes)
>
>  static ssize_t notes_read(struct file *filp, struct kobject *kobj,
> diff --git a/lib/buildid.c b/lib/buildid.c
> index 898301b49eb6..7954dd92e36c 100644
> --- a/lib/buildid.c
> +++ b/lib/buildid.c
> @@ -182,8 +182,8 @@ unsigned char vmlinux_build_id[BUILD_ID_SIZE_MAX] __ro_after_init;
>   */
>  void __init init_vmlinux_build_id(void)
>  {
> -       extern const void __start_notes __weak;
> -       extern const void __stop_notes __weak;
> +       extern const void __start_notes;
> +       extern const void __stop_notes;
>         unsigned int size = &__stop_notes - &__start_notes;
>
>         build_id_parse_buf(&__start_notes, vmlinux_build_id, size);
> --
> 2.44.0.683.g7961c838ac-goog
>
>


-- 
Best Regards
Masahiro Yamada

[PATCH v4 3/3] btf: Avoid weak external references

[Ard Biesheuvel]

From: Ard Biesheuvel <ardb@kernel.org>

If the BTF code is enabled in the build configuration, the start/stop
BTF markers are guaranteed to exist. Only when CONFIG_DEBUG_INFO_BTF=n,
the references in btf_parse_vmlinux() will remain unsatisfied, relying
on the weak linkage of the external references to avoid breaking the
build.

Avoid GOT based relocations to these markers in the final executable by
dropping the weak attribute and instead, make btf_parse_vmlinux() return
ERR_PTR(-ENOENT) directly if CONFIG_DEBUG_INFO_BTF is not enabled to
begin with.  The compiler will drop any subsequent references to
__start_BTF and __stop_BTF in that case, allowing the link to succeed.

Note that Clang will notice that taking the address of __start_BTF can
no longer yield NULL, so testing for that condition becomes unnecessary.

Acked-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 kernel/bpf/btf.c       | 7 +++++--
 kernel/bpf/sysfs_btf.c | 6 +++---
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 90c4a32d89ff..6d46cee47ae3 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -5642,8 +5642,8 @@ static struct btf *btf_parse(const union bpf_attr *attr, bpfptr_t uattr, u32 uat
 	return ERR_PTR(err);
 }
 
-extern char __weak __start_BTF[];
-extern char __weak __stop_BTF[];
+extern char __start_BTF[];
+extern char __stop_BTF[];
 extern struct btf *btf_vmlinux;
 
 #define BPF_MAP_TYPE(_id, _ops)
@@ -5971,6 +5971,9 @@ struct btf *btf_parse_vmlinux(void)
 	struct btf *btf = NULL;
 	int err;
 
+	if (!IS_ENABLED(CONFIG_DEBUG_INFO_BTF))
+		return ERR_PTR(-ENOENT);
+
 	env = kzalloc(sizeof(*env), GFP_KERNEL | __GFP_NOWARN);
 	if (!env)
 		return ERR_PTR(-ENOMEM);
diff --git a/kernel/bpf/sysfs_btf.c b/kernel/bpf/sysfs_btf.c
index ef6911aee3bb..fedb54c94cdb 100644
--- a/kernel/bpf/sysfs_btf.c
+++ b/kernel/bpf/sysfs_btf.c
@@ -9,8 +9,8 @@
 #include <linux/sysfs.h>
 
 /* See scripts/link-vmlinux.sh, gen_btf() func for details */
-extern char __weak __start_BTF[];
-extern char __weak __stop_BTF[];
+extern char __start_BTF[];
+extern char __stop_BTF[];
 
 static ssize_t
 btf_vmlinux_read(struct file *file, struct kobject *kobj,
@@ -32,7 +32,7 @@ static int __init btf_vmlinux_init(void)
 {
 	bin_attr_btf_vmlinux.size = __stop_BTF - __start_BTF;
 
-	if (!__start_BTF || bin_attr_btf_vmlinux.size == 0)
+	if (bin_attr_btf_vmlinux.size == 0)
 		return 0;
 
 	btf_kobj = kobject_create_and_add("btf", kernel_kobj);
-- 
2.44.0.683.g7961c838ac-goog

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Daniel Borkmann <daniel@iogearbox.net>:

On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> Weak external linkage is intended for cases where a symbol reference
> can remain unsatisfied in the final link. Taking the address of such a
> symbol should yield NULL if the reference was not satisfied.
> 
> Given that ordinary RIP or PC relative references cannot produce NULL,
> some kind of indirection is always needed in such cases, and in position
> independent code, this results in a GOT entry. In ordinary code, it is
> arch specific but amounts to the same thing.
> 
> [...]

Here is the summary with links:
  - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
    (no matching commit)
  - [v4,2/3] vmlinux: Avoid weak reference to notes section
    (no matching commit)
  - [v4,3/3] btf: Avoid weak external references
    https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Ard Biesheuvel]

On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
>
> Hello:
>
> This series was applied to bpf/bpf-next.git (master)
> by Daniel Borkmann <daniel@iogearbox.net>:
>
> On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Weak external linkage is intended for cases where a symbol reference
> > can remain unsatisfied in the final link. Taking the address of such a
> > symbol should yield NULL if the reference was not satisfied.
> >
> > Given that ordinary RIP or PC relative references cannot produce NULL,
> > some kind of indirection is always needed in such cases, and in position
> > independent code, this results in a GOT entry. In ordinary code, it is
> > arch specific but amounts to the same thing.
> >
> > [...]
>
> Here is the summary with links:
>   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
>     (no matching commit)
>   - [v4,2/3] vmlinux: Avoid weak reference to notes section
>     (no matching commit)
>   - [v4,3/3] btf: Avoid weak external references
>     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
>


Thanks.

Masahiro, could you pick up patches #1 and #2 please?

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Masahiro Yamada]

On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> >
> > Hello:
> >
> > This series was applied to bpf/bpf-next.git (master)
> > by Daniel Borkmann <daniel@iogearbox.net>:
> >
> > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > From: Ard Biesheuvel <ardb@kernel.org>
> > >
> > > Weak external linkage is intended for cases where a symbol reference
> > > can remain unsatisfied in the final link. Taking the address of such a
> > > symbol should yield NULL if the reference was not satisfied.
> > >
> > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > some kind of indirection is always needed in such cases, and in position
> > > independent code, this results in a GOT entry. In ordinary code, it is
> > > arch specific but amounts to the same thing.
> > >
> > > [...]
> >
> > Here is the summary with links:
> >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> >     (no matching commit)
> >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> >     (no matching commit)
> >   - [v4,3/3] btf: Avoid weak external references
> >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> >
>
>
> Thanks.
>
> Masahiro, could you pick up patches #1 and #2 please?
>


I do not like PROVIDE() because it potentially shifts
a build error (i.e. link error) into
a run-time error, which is usually more difficult to debug
than build error.

If someone references the kallsyms_* symbols
when CONFIG_KALLSYMS=n, it is likely a mistake.
In general, it should be reported as a link error.

With PROVIDE() added, we will never detect it
at a build time.

Do you want me to pick up 1/3?







--
Best Regards
Masahiro Yamada

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Ard Biesheuvel]

On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> > >
> > > Hello:
> > >
> > > This series was applied to bpf/bpf-next.git (master)
> > > by Daniel Borkmann <daniel@iogearbox.net>:
> > >
> > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > >
> > > > Weak external linkage is intended for cases where a symbol reference
> > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > symbol should yield NULL if the reference was not satisfied.
> > > >
> > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > some kind of indirection is always needed in such cases, and in position
> > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > arch specific but amounts to the same thing.
> > > >
> > > > [...]
> > >
> > > Here is the summary with links:
> > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > >     (no matching commit)
> > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > >     (no matching commit)
> > >   - [v4,3/3] btf: Avoid weak external references
> > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > >
> >
> >
> > Thanks.
> >
> > Masahiro, could you pick up patches #1 and #2 please?
> >
>
>
> I do not like PROVIDE() because it potentially shifts
> a build error (i.e. link error) into
> a run-time error, which is usually more difficult to debug
> than build error.
>
> If someone references the kallsyms_* symbols
> when CONFIG_KALLSYMS=n, it is likely a mistake.
> In general, it should be reported as a link error.
>

OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.

> With PROVIDE() added, we will never detect it
> at a build time.
>
> Do you want me to pick up 1/3?
>

???

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Masahiro Yamada]

On Sat, Apr 20, 2024 at 9:35 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> > > >
> > > > Hello:
> > > >
> > > > This series was applied to bpf/bpf-next.git (master)
> > > > by Daniel Borkmann <daniel@iogearbox.net>:
> > > >
> > > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > >
> > > > > Weak external linkage is intended for cases where a symbol reference
> > > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > > symbol should yield NULL if the reference was not satisfied.
> > > > >
> > > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > > some kind of indirection is always needed in such cases, and in position
> > > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > > arch specific but amounts to the same thing.
> > > > >
> > > > > [...]
> > > >
> > > > Here is the summary with links:
> > > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > > >     (no matching commit)
> > > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > > >     (no matching commit)
> > > >   - [v4,3/3] btf: Avoid weak external references
> > > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > > >
> > >
> > >
> > > Thanks.
> > >
> > > Masahiro, could you pick up patches #1 and #2 please?
> > >
> >
> >
> > I do not like PROVIDE() because it potentially shifts
> > a build error (i.e. link error) into
> > a run-time error, which is usually more difficult to debug
> > than build error.
> >
> > If someone references the kallsyms_* symbols
> > when CONFIG_KALLSYMS=n, it is likely a mistake.
> > In general, it should be reported as a link error.
> >
>
> OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.


You may need to take care of the dependency
between CONFIG_KALLSYMS and CONFIG_VMCORE_INFO
because kernel/vmcore_info.c has references
to the kallsyms_* symbols.

(I am still not a big fan of PROVIDE() though)




>
> > With PROVIDE() added, we will never detect it
> > at a build time.
> >
> > Do you want me to pick up 1/3?
> >
>
> ???

I will apply 2/3.
It is trivial.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Ard Biesheuvel]

On Sat, 20 Apr 2024 at 15:42, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Sat, Apr 20, 2024 at 9:35 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> > > > >
> > > > > Hello:
> > > > >
> > > > > This series was applied to bpf/bpf-next.git (master)
> > > > > by Daniel Borkmann <daniel@iogearbox.net>:
> > > > >
> > > > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > > >
> > > > > > Weak external linkage is intended for cases where a symbol reference
> > > > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > > > symbol should yield NULL if the reference was not satisfied.
> > > > > >
> > > > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > > > some kind of indirection is always needed in such cases, and in position
> > > > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > > > arch specific but amounts to the same thing.
> > > > > >
> > > > > > [...]
> > > > >
> > > > > Here is the summary with links:
> > > > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > > > >     (no matching commit)
> > > > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > > > >     (no matching commit)
> > > > >   - [v4,3/3] btf: Avoid weak external references
> > > > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > > Masahiro, could you pick up patches #1 and #2 please?
> > > >
> > >
> > >
> > > I do not like PROVIDE() because it potentially shifts
> > > a build error (i.e. link error) into
> > > a run-time error, which is usually more difficult to debug
> > > than build error.
> > >
> > > If someone references the kallsyms_* symbols
> > > when CONFIG_KALLSYMS=n, it is likely a mistake.
> > > In general, it should be reported as a link error.
> > >
> >
> > OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.
>
>
> You may need to take care of the dependency
> between CONFIG_KALLSYMS and CONFIG_VMCORE_INFO
> because kernel/vmcore_info.c has references
> to the kallsyms_* symbols.
>
> (I am still not a big fan of PROVIDE() though)
>


OK, how about we use weak definitions (as opposed to weak references)
in kernel/kallsyms.c, which will get superseded by the actual ones in
the second linker pass.

The only difference is that we will use some space in the binary for
the weak definitions that are never used in the final build.

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Ard Biesheuvel]

On Sat, 20 Apr 2024 at 15:56, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sat, 20 Apr 2024 at 15:42, Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Sat, Apr 20, 2024 at 9:35 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > >
> > > > > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> > > > > >
> > > > > > Hello:
> > > > > >
> > > > > > This series was applied to bpf/bpf-next.git (master)
> > > > > > by Daniel Borkmann <daniel@iogearbox.net>:
> > > > > >
> > > > > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > > > >
> > > > > > > Weak external linkage is intended for cases where a symbol reference
> > > > > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > > > > symbol should yield NULL if the reference was not satisfied.
> > > > > > >
> > > > > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > > > > some kind of indirection is always needed in such cases, and in position
> > > > > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > > > > arch specific but amounts to the same thing.
> > > > > > >
> > > > > > > [...]
> > > > > >
> > > > > > Here is the summary with links:
> > > > > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > > > > >     (no matching commit)
> > > > > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > > > > >     (no matching commit)
> > > > > >   - [v4,3/3] btf: Avoid weak external references
> > > > > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > > Masahiro, could you pick up patches #1 and #2 please?
> > > > >
> > > >
> > > >
> > > > I do not like PROVIDE() because it potentially shifts
> > > > a build error (i.e. link error) into
> > > > a run-time error, which is usually more difficult to debug
> > > > than build error.
> > > >
> > > > If someone references the kallsyms_* symbols
> > > > when CONFIG_KALLSYMS=n, it is likely a mistake.
> > > > In general, it should be reported as a link error.
> > > >
> > >
> > > OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.
> >
> >
> > You may need to take care of the dependency
> > between CONFIG_KALLSYMS and CONFIG_VMCORE_INFO
> > because kernel/vmcore_info.c has references
> > to the kallsyms_* symbols.
> >
> > (I am still not a big fan of PROVIDE() though)
> >
>
>
> OK, how about we use weak definitions (as opposed to weak references)
> in kernel/kallsyms.c, which will get superseded by the actual ones in
> the second linker pass.
>
> The only difference is that we will use some space in the binary for
> the weak definitions that are never used in the final build.

Btw those references in kernel/vmcore_info.c are guarded by #ifdef
CONFIG_KALLSYMS=y too.

Re: [PATCH v4 0/3] kbuild: Avoid weak external linkage where possible

[Masahiro Yamada]

On Sat, Apr 20, 2024 at 11:00 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Sat, 20 Apr 2024 at 15:56, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Sat, 20 Apr 2024 at 15:42, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Sat, Apr 20, 2024 at 9:35 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Sat, 20 Apr 2024 at 14:32, Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > > >
> > > > > On Fri, Apr 19, 2024 at 4:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, 16 Apr 2024 at 16:40, <patchwork-bot+netdevbpf@kernel.org> wrote:
> > > > > > >
> > > > > > > Hello:
> > > > > > >
> > > > > > > This series was applied to bpf/bpf-next.git (master)
> > > > > > > by Daniel Borkmann <daniel@iogearbox.net>:
> > > > > > >
> > > > > > > On Mon, 15 Apr 2024 18:20:42 +0200 you wrote:
> > > > > > > > From: Ard Biesheuvel <ardb@kernel.org>
> > > > > > > >
> > > > > > > > Weak external linkage is intended for cases where a symbol reference
> > > > > > > > can remain unsatisfied in the final link. Taking the address of such a
> > > > > > > > symbol should yield NULL if the reference was not satisfied.
> > > > > > > >
> > > > > > > > Given that ordinary RIP or PC relative references cannot produce NULL,
> > > > > > > > some kind of indirection is always needed in such cases, and in position
> > > > > > > > independent code, this results in a GOT entry. In ordinary code, it is
> > > > > > > > arch specific but amounts to the same thing.
> > > > > > > >
> > > > > > > > [...]
> > > > > > >
> > > > > > > Here is the summary with links:
> > > > > > >   - [v4,1/3] kallsyms: Avoid weak references for kallsyms symbols
> > > > > > >     (no matching commit)
> > > > > > >   - [v4,2/3] vmlinux: Avoid weak reference to notes section
> > > > > > >     (no matching commit)
> > > > > > >   - [v4,3/3] btf: Avoid weak external references
> > > > > > >     https://git.kernel.org/bpf/bpf-next/c/fc5eb4a84e4c
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Masahiro, could you pick up patches #1 and #2 please?
> > > > > >
> > > > >
> > > > >
> > > > > I do not like PROVIDE() because it potentially shifts
> > > > > a build error (i.e. link error) into
> > > > > a run-time error, which is usually more difficult to debug
> > > > > than build error.
> > > > >
> > > > > If someone references the kallsyms_* symbols
> > > > > when CONFIG_KALLSYMS=n, it is likely a mistake.
> > > > > In general, it should be reported as a link error.
> > > > >
> > > >
> > > > OK, so the PROVIDE() should be conditional on CONFIG_KALLSYM=y. I can fix that.
> > >
> > >
> > > You may need to take care of the dependency
> > > between CONFIG_KALLSYMS and CONFIG_VMCORE_INFO
> > > because kernel/vmcore_info.c has references
> > > to the kallsyms_* symbols.
> > >
> > > (I am still not a big fan of PROVIDE() though)
> > >
> >
> >
> > OK, how about we use weak definitions (as opposed to weak references)
> > in kernel/kallsyms.c, which will get superseded by the actual ones in
> > the second linker pass.
> >
> > The only difference is that we will use some space in the binary for
> > the weak definitions that are never used in the final build.


I am fine if that fixes the issue.


"git grep __weak" shows a bunch of weak definitions.




> Btw those references in kernel/vmcore_info.c are guarded by #ifdef
> CONFIG_KALLSYMS=y too.

Ah, OK.
Then, this is not an issue.


-- 
Best Regards
Masahiro Yamada