public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jessica Yu <jeyu@kernel.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Laura Abbott <labbott@redhat.com>,
	Martin Sebor <msebor@gcc.gnu.org>, Arnd Bergmann <arnd@arndb.de>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	James Morris <james.morris@microsoft.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Borislav Petkov <bp@suse.de>, Kees Cook <keescook@chromium.org>,
	Matt Mullins <mmullins@fb.com>,
	Vincent Whitchurch <vincent.whitchurch@axis.com>,
	WANG Chao <chao.wang@ucloud.cn>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] include/linux/module.h: copy __init/__exit attrs to init/cleanup_module
Date: Mon, 11 Feb 2019 16:01:09 +0100	[thread overview]
Message-ID: <20190211150108.GB20732@linux-8ccs> (raw)
In-Reply-To: <20190209000840.11018-4-miguel.ojeda.sandonis@gmail.com>

+++ Miguel Ojeda [09/02/19 01:08 +0100]:
>The upcoming GCC 9 release extends the -Wmissing-attributes warnings
>(enabled by -Wall) to C and aliases: it warns when particular function
>attributes are missing in the aliases but not in their target.
>
>In particular, it triggers for all the init/cleanup_module
>aliases in the kernel (defined by the module_init/exit macros),
>ending up being very noisy.
>
>These aliases point to the __init/__exit functions of a module,
>which are defined as __cold (among other attributes). However,
>the aliases themselves do not have the __cold attribute.
>
>Since the compiler behaves differently when compiling a __cold
>function as well as when compiling paths leading to calls
>to __cold functions, the warning is trying to point out
>the possibly-forgotten attribute in the alias.
>
>In order to keep the warning enabled, we decided to silence
>this case. Ideally, we would mark the aliases directly
>as __init/__exit. However, there are currently around 132 modules
>in the kernel which are missing __init/__exit in their init/cleanup
>functions (either because they are missing, or for other reasons,
>e.g. the functions being called from somewhere else); and
>a section mismatch is a hard error.
>
>A conservative alternative was to mark the aliases as __cold only.
>However, since we would like to eventually enforce __init/__exit
>to be always marked,  we chose to use the new __copy function
>attribute (introduced by GCC 9 as well to deal with this).
>With it, we copy the attributes used by the target functions
>into the aliases. This way, functions that were not marked
>as __init/__exit won't have their aliases marked either,
>and therefore there won't be a section mismatch.
>
>Note that the warning would go away marking either the extern
>declaration, the definition, or both. However, we only mark
>the definition of the alias, since we do not want callers
>(which only see the declaration) to be compiled as if the function
>was __cold (and therefore the paths leading to those calls
>would be assumed to be unlikely).
>
>Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/
>Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/
>Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
>Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

Acked-by: Jessica Yu <jeyu@kernel.org>

Thanks!

>---
> include/linux/module.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/include/linux/module.h b/include/linux/module.h
>index 8fa38d3e7538..f5bc4c046461 100644
>--- a/include/linux/module.h
>+++ b/include/linux/module.h
>@@ -129,13 +129,13 @@ extern void cleanup_module(void);
> #define module_init(initfn)					\
> 	static inline initcall_t __maybe_unused __inittest(void)		\
> 	{ return initfn; }					\
>-	int init_module(void) __attribute__((alias(#initfn)));
>+	int init_module(void) __copy(initfn) __attribute__((alias(#initfn)));
>
> /* This is only required if you want to be unloadable. */
> #define module_exit(exitfn)					\
> 	static inline exitcall_t __maybe_unused __exittest(void)		\
> 	{ return exitfn; }					\
>-	void cleanup_module(void) __attribute__((alias(#exitfn)));
>+	void cleanup_module(void) __copy(exitfn) __attribute__((alias(#exitfn)));
>
> #endif
>
>-- 
>2.17.1
>

  reply	other threads:[~2019-02-11 15:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09  0:08 [PATCH 0/3] Clean the new GCC 9 -Wmissing-attributes warnings Miguel Ojeda
2019-02-09  0:08 ` [PATCH 1/3] lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as __pure Miguel Ojeda
2019-02-09  0:08 ` [PATCH 2/3] Compiler Attributes: add support for __copy (gcc >= 9) Miguel Ojeda
2019-02-09  0:41   ` Nick Desaulniers
2019-02-09 12:36     ` Miguel Ojeda
2019-02-09  0:08 ` [PATCH 3/3] include/linux/module.h: copy __init/__exit attrs to init/cleanup_module Miguel Ojeda
2019-02-11 15:01   ` Jessica Yu [this message]
2019-02-09 10:44 ` [PATCH 0/3] Clean the new GCC 9 -Wmissing-attributes warnings Ard Biesheuvel
2019-02-09 11:19   ` Miguel Ojeda
2019-02-09 11:25     ` Ard Biesheuvel
2019-02-09 12:31       ` Miguel Ojeda
2019-02-11 16:21         ` Martin Sebor
2019-02-11 18:20           ` Ard Biesheuvel
2019-02-09 20:32 ` Laura Abbott
2019-02-13 17:30   ` Miguel Ojeda

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=20190211150108.GB20732@linux-8ccs \
    --to=jeyu@kernel.org \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=chao.wang@ucloud.cn \
    --cc=james.morris@microsoft.com \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mmullins@fb.com \
    --cc=msebor@gcc.gnu.org \
    --cc=vincent.whitchurch@axis.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox