2020-12-03 23:13:35

by Arnd Bergmann

[permalink] [raw]
Subject: [PATCH] kbuild: avoid static_assert for genksyms

From: Arnd Bergmann <[email protected]>

genksyms does not know or care about the _Static_assert() built-in,
and sometimes falls back to ignoring the later symbols, which causes
undefined behavior such as

WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation

Redefine static_assert for genksyms to avoid that.

Cc: [email protected]
Suggested-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
---
include/linux/build_bug.h | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
index e3a0be2c90ad..7bb66e15b481 100644
--- a/include/linux/build_bug.h
+++ b/include/linux/build_bug.h
@@ -77,4 +77,9 @@
#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)

+#ifdef __GENKSYMS__
+/* genksyms gets confused by _Static_assert */
+#define _Static_assert(expr, ...)
+#endif
+
#endif /* _LINUX_BUILD_BUG_H */
--
2.27.0


2020-12-06 04:15:11

by Masahiro Yamada

[permalink] [raw]
Subject: Re: [PATCH] kbuild: avoid static_assert for genksyms

On Fri, Dec 4, 2020 at 8:10 AM Arnd Bergmann <[email protected]> wrote:
>
> From: Arnd Bergmann <[email protected]>
>
> genksyms does not know or care about the _Static_assert() built-in,
> and sometimes falls back to ignoring the later symbols, which causes
> undefined behavior such as
>
> WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
> ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
> net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation
>
> Redefine static_assert for genksyms to avoid that.


Please tell the CONFIG options needed to reproduce this.
I do not see it.


>
> Cc: [email protected]
> Suggested-by: Ard Biesheuvel <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> include/linux/build_bug.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
> index e3a0be2c90ad..7bb66e15b481 100644
> --- a/include/linux/build_bug.h
> +++ b/include/linux/build_bug.h
> @@ -77,4 +77,9 @@
> #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
> #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>
> +#ifdef __GENKSYMS__
> +/* genksyms gets confused by _Static_assert */
> +#define _Static_assert(expr, ...)
> +#endif
> +
> #endif /* _LINUX_BUILD_BUG_H */
> --
> 2.27.0
>


--
Best Regards
Masahiro Yamada

2020-12-07 08:56:40

by Ard Biesheuvel

[permalink] [raw]
Subject: Re: [PATCH] kbuild: avoid static_assert for genksyms

On Sun, 6 Dec 2020 at 03:49, Masahiro Yamada <[email protected]> wrote:
>
> On Fri, Dec 4, 2020 at 8:10 AM Arnd Bergmann <[email protected]> wrote:
> >
> > From: Arnd Bergmann <[email protected]>
> >
> > genksyms does not know or care about the _Static_assert() built-in,
> > and sometimes falls back to ignoring the later symbols, which causes
> > undefined behavior such as
> >
> > WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
> > ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
> > net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation
> >
> > Redefine static_assert for genksyms to avoid that.
>
>
> Please tell the CONFIG options needed to reproduce this.
> I do not see it.
>

https://people.linaro.org/~ard.biesheuvel/randconfig-modversions-error

2020-12-11 15:03:24

by Marco Elver

[permalink] [raw]
Subject: Re: [PATCH] kbuild: avoid static_assert for genksyms

On Fri, Dec 04, 2020 at 12:09AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <[email protected]>
>
> genksyms does not know or care about the _Static_assert() built-in,
> and sometimes falls back to ignoring the later symbols, which causes
> undefined behavior such as
>
> WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
> ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
> net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation
>
> Redefine static_assert for genksyms to avoid that.
>
> Cc: [email protected]
> Suggested-by: Ard Biesheuvel <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> ---
> include/linux/build_bug.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/build_bug.h b/include/linux/build_bug.h
> index e3a0be2c90ad..7bb66e15b481 100644
> --- a/include/linux/build_bug.h
> +++ b/include/linux/build_bug.h
> @@ -77,4 +77,9 @@
> #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
> #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>
> +#ifdef __GENKSYMS__
> +/* genksyms gets confused by _Static_assert */
> +#define _Static_assert(expr, ...)
> +#endif
> +

I had sent

https://lkml.kernel.org/r/[email protected]

3 days before your patch. :-)

I guess what you propose is simpler, but might still have corner cases
where we still get warnings. In particular, if some file (for whatever
reason) does not include build_bug.h and uses a raw _Static_assert(),
then we still get warnings. E.g. I see 1 user of raw _Static_assert()
(drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h ).

In the end I don't mind either way, as long as those warnings are fixed
in 5.11. :-)

Thanks,
-- Marco