LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Jessica Yu <jeyu@kernel.org>
Cc: Laura Abbott <labbott@redhat.com>,
	Martin Sebor <msebor@gcc.gnu.org>,
	linux-kernel@vger.kernel.org
Subject: [PATCH] include/linux/module.h: mark init/cleanup_module aliases as __cold
Date: Wed, 23 Jan 2019 18:37:07 +0100
Message-ID: <20190123173707.GA16603@gmail.com> (raw)

The upcoming GCC 9 release adds the -Wmissing-attributes warnings
(enabled by -Wall), which trigger 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 choose to silence
the warning by marking the aliases as __cold. This is possible
marking either the extern declaration, the definition, or both.
In order to avoid changing the behavior of callers, we do it
only in the definition of the aliases (since those are not
seen by any other TU).

Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
Note that an alternative is using the new copy attribute
introduced by GCC 9 (Martin told me about it, as well as the
new warning).

What I am concerned about using __copy is that I am not sure
we should be copying all the attributes (even if some are
blacklisted by the copy itself), since:
  - We have unknown-to-GCC attributes (e.g. from plugins).
  - We wouldn't enjoy the fix for older compilers
    (e.g. if the fix had an actual impact).

So here I took the conservative approach for the moment,
and we can discuss/apply whether another solution is best.

Jessica: please review what I explain in the commit message.
Do we actually want the __cold attribute in the declaration
as well? If yes, AFAIK, GCC would assume paths that end up
calling the __init/__exit functions are not meant to be taken
(but when we are asked to load modules, that is the expected
path, no?).

I will put this in the compiler-attributes tree and get
some time in linux-next, unless you want to pick it up!

 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..c4e805e87628 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) __cold __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) __cold __attribute__((alias(#exitfn)));
 
 #endif
 
-- 
2.17.1


             reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 17:37 Miguel Ojeda [this message]
2019-01-25 10:47 ` Laura Abbott
2019-01-31 14:22 ` Jessica Yu
2019-01-31 16:48   ` Miguel Ojeda
2019-02-04 15:08     ` Jessica Yu
2019-02-06 16:31       ` Miguel Ojeda
2019-02-06 17:28         ` Miguel Ojeda

Reply instructions:

You may reply publically 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=20190123173707.GA16603@gmail.com \
    --to=miguel.ojeda.sandonis@gmail.com \
    --cc=jeyu@kernel.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msebor@gcc.gnu.org \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git