All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kbuild@vger.kernel.org,
	Masahiro Yamada <masahiroy@kernel.org>,
	Michal Marek <michal.lkml@markovi.net>,
	Arnd Bergmann <arnd@arndb.de>,
	stable@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Rikard Falkeborn <rikard.falkeborn@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kbuild: avoid static_assert for genksyms
Date: Thu, 10 Dec 2020 17:12:20 +0100	[thread overview]
Message-ID: <X9JI5KpWoo23wkRg@elver.google.com> (raw)
In-Reply-To: <20201203230955.1482058-1-arnd@kernel.org>

On Fri, Dec 04, 2020 at 12:09AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> 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: stable@vger.kernel.org
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  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/20201201152017.3576951-1-elver@google.com

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

      parent reply	other threads:[~2020-12-10 16:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-03 23:09 [PATCH] kbuild: avoid static_assert for genksyms Arnd Bergmann
2020-12-06  2:48 ` Masahiro Yamada
2020-12-07  8:53   ` Ard Biesheuvel
2020-12-10 16:12 ` Marco Elver [this message]

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=X9JI5KpWoo23wkRg@elver.google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=rikard.falkeborn@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=yamada.masahiro@socionext.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.