linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	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: [PATCH 3/3] include/linux/module.h: copy __init/__exit attrs to init/cleanup_module
Date: Sat,  9 Feb 2019 01:08:40 +0100	[thread overview]
Message-ID: <20190209000840.11018-4-miguel.ojeda.sandonis@gmail.com> (raw)
In-Reply-To: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com>

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>
---
 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


  parent reply	other threads:[~2019-02-09  0:09 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 ` Miguel Ojeda [this message]
2019-02-11 15:01   ` [PATCH 3/3] include/linux/module.h: copy __init/__exit attrs to init/cleanup_module Jessica Yu
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=20190209000840.11018-4-miguel.ojeda.sandonis@gmail.com \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bp@suse.de \
    --cc=chao.wang@ucloud.cn \
    --cc=james.morris@microsoft.com \
    --cc=jeyu@kernel.org \
    --cc=keescook@chromium.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.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;
as well as URLs for NNTP newsgroup(s).