a4462ff
From patchwork Wed Jan 23 17:37:07 2019
a4462ff
Content-Type: text/plain; charset="utf-8"
a4462ff
MIME-Version: 1.0
a4462ff
Content-Transfer-Encoding: 7bit
a4462ff
X-Patchwork-Submitter: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
a4462ff
X-Patchwork-Id: 1034989
a4462ff
Return-Path: <SRS0=drEb=P7=vger.kernel.org=linux-kernel-owner@kernel.org>
a4462ff
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
a4462ff
	by smtp.lore.kernel.org (Postfix) with ESMTP id A7D50C282C0
a4462ff
	for <linux-kernel@archiver.kernel.org>; Wed, 23 Jan 2019 17:38:31 +0000 (UTC)
a4462ff
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
a4462ff
	by mail.kernel.org (Postfix) with ESMTP id 7CE1F20870
a4462ff
	for <linux-kernel@archiver.kernel.org>; Wed, 23 Jan 2019 17:38:31 +0000 (UTC)
a4462ff
Authentication-Results: mail.kernel.org;
a4462ff
	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
a4462ff
 header.b="qdRA7oPl"
a4462ff
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
a4462ff
        id S1726152AbfAWRi3 (ORCPT
a4462ff
        <rfc822;linux-kernel@archiver.kernel.org>);
a4462ff
        Wed, 23 Jan 2019 12:38:29 -0500
a4462ff
Received: from mail-wm1-f67.google.com ([209.85.128.67]:52719 "EHLO
a4462ff
        mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
a4462ff
        with ESMTP id S1725896AbfAWRi3 (ORCPT
a4462ff
        <rfc822;linux-kernel@vger.kernel.org>);
a4462ff
        Wed, 23 Jan 2019 12:38:29 -0500
a4462ff
Received: by mail-wm1-f67.google.com with SMTP id m1so242485wml.2
a4462ff
        for <linux-kernel@vger.kernel.org>;
a4462ff
 Wed, 23 Jan 2019 09:38:27 -0800 (PST)
a4462ff
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
a4462ff
        d=gmail.com; s=20161025;
a4462ff
        h=date:from:to:cc:subject:message-id:mime-version:content-disposition
a4462ff
         :user-agent;
a4462ff
        bh=1joVTuHcQFv5PhIFvZBlpu1jeKwRQi2Ty1HKsqzNx+0=;
a4462ff
        b=qdRA7oPloipduZyiYE/EECaW/vCZup5EXmE5a1XgE9mc55H+TTPNNRTt44QJbQgbnn
a4462ff
         wTNksIkBx8Gs0k3pJI9QIDO2J5AipLN8OOoxkPiDIJtAC8buHzQrdTxFG/4Uxw7tRf8X
a4462ff
         A6PNyuUGr+02itkYIlALzEuDHvZna8yZx0zCeCDXF2IrGt0NBHZVTzz1XfX8LeQlCh9L
a4462ff
         hleyVdDQnDvwxA7dXqrA4UugXUlEqT8HnIAUdg8+/xubsXOSz9T/22+zc9pZ9uSHm2uq
a4462ff
         DpO/hgx1e5DONDN8T+sjjKCO0LnJ8Z9ZS0Huf+8W2XH1uxo48jSgXUOsygPQ36+8R/7t
a4462ff
         ng6Q==
a4462ff
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
a4462ff
        d=1e100.net; s=20161025;
a4462ff
        h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
a4462ff
         :content-disposition:user-agent;
a4462ff
        bh=1joVTuHcQFv5PhIFvZBlpu1jeKwRQi2Ty1HKsqzNx+0=;
a4462ff
        b=ZQrXdTIYsCSUGNJS1C0dn+gibvoSHb2o+kcUMGTbH6G2tag3Zy4vnfIcBT0xhmvPLq
a4462ff
         5pU8jskcufXp0qQ0sivNsBpJYJCbsqqiChoivTs9WC4rxoM5G62Wi0pAZL59fGGDnmyV
a4462ff
         xjSTkSoxe8CiB+26BDzg52zkynkWC2v0OHgaM7/1lTeTqNxdYIvQ+hC4LXdy40bAP64/
a4462ff
         JIC1nET+KwewpPHJQc2u87ah4xp6nEjzO/4wTP3CUi4zbZPTU17oH007IAXhObL7JO0r
a4462ff
         XkRBJAgpcTKexfAJB7HnAUc4KLSv5L5Uz+Z14TusskTuK6njE11PE9GSJ7Z7lqufqJNZ
a4462ff
         Z4GQ==
a4462ff
X-Gm-Message-State: AJcUukdaW+EjUkHLIrpaLWRYCoF9XYWdpSiPfNnJgu3VB9CW8t9xYlZJ
a4462ff
        NDU6hJ2AXvnDR+awfdjm6IU=
a4462ff
X-Google-Smtp-Source: 
a4462ff
 ALg8bN59XklA0HTVEDaLFI+8dguNdipIQWTlgIi23N78PjaLBzniLMXowf2nCpIra7boIidjtFvfYg==
a4462ff
X-Received: by 2002:a1c:7c05:: with SMTP id x5mr3525198wmc.54.1548265106544;
a4462ff
        Wed, 23 Jan 2019 09:38:26 -0800 (PST)
a4462ff
Received: from gmail.com (79.108.96.12.dyn.user.ono.com. [79.108.96.12])
a4462ff
        by smtp.gmail.com with ESMTPSA id
a4462ff
 r77sm74200791wmd.22.2019.01.23.09.38.25
a4462ff
        (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
a4462ff
        Wed, 23 Jan 2019 09:38:25 -0800 (PST)
a4462ff
Date: Wed, 23 Jan 2019 18:37:07 +0100
a4462ff
From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
a4462ff
To: Jessica Yu <jeyu@kernel.org>
a4462ff
Cc: Laura Abbott <labbott@redhat.com>,
a4462ff
        Martin Sebor <msebor@gcc.gnu.org>, linux-kernel@vger.kernel.org
a4462ff
Subject: [PATCH] include/linux/module.h: mark init/cleanup_module aliases as
a4462ff
 __cold
a4462ff
Message-ID: <20190123173707.GA16603@gmail.com>
a4462ff
MIME-Version: 1.0
a4462ff
Content-Type: text/plain; charset=us-ascii
a4462ff
Content-Disposition: inline
a4462ff
User-Agent: elm/2
a4462ff
Sender: linux-kernel-owner@vger.kernel.org
a4462ff
Precedence: bulk
a4462ff
List-ID: <linux-kernel.vger.kernel.org>
a4462ff
X-Mailing-List: linux-kernel@vger.kernel.org
a4462ff
a4462ff
The upcoming GCC 9 release adds the -Wmissing-attributes warnings
a4462ff
(enabled by -Wall), which trigger for all the init/cleanup_module
a4462ff
aliases in the kernel (defined by the module_init/exit macros),
a4462ff
ending up being very noisy.
a4462ff
a4462ff
These aliases point to the __init/__exit functions of a module,
a4462ff
which are defined as __cold (among other attributes). However,
a4462ff
the aliases themselves do not have the __cold attribute.
a4462ff
a4462ff
Since the compiler behaves differently when compiling a __cold
a4462ff
function as well as when compiling paths leading to calls
a4462ff
to __cold functions, the warning is trying to point out
a4462ff
the possibly-forgotten attribute in the alias.
a4462ff
a4462ff
In order to keep the warning enabled, we choose to silence
a4462ff
the warning by marking the aliases as __cold. This is possible
a4462ff
marking either the extern declaration, the definition, or both.
a4462ff
In order to avoid changing the behavior of callers, we do it
a4462ff
only in the definition of the aliases (since those are not
a4462ff
seen by any other TU).
a4462ff
a4462ff
Suggested-by: Martin Sebor <msebor@gcc.gnu.org>
a4462ff
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
a4462ff
---
a4462ff
Note that an alternative is using the new copy attribute
a4462ff
introduced by GCC 9 (Martin told me about it, as well as the
a4462ff
new warning).
a4462ff
a4462ff
What I am concerned about using __copy is that I am not sure
a4462ff
we should be copying all the attributes (even if some are
a4462ff
blacklisted by the copy itself), since:
a4462ff
  - We have unknown-to-GCC attributes (e.g. from plugins).
a4462ff
  - We wouldn't enjoy the fix for older compilers
a4462ff
    (e.g. if the fix had an actual impact).
a4462ff
a4462ff
So here I took the conservative approach for the moment,
a4462ff
and we can discuss/apply whether another solution is best.
a4462ff
a4462ff
Jessica: please review what I explain in the commit message.
a4462ff
Do we actually want the __cold attribute in the declaration
a4462ff
as well? If yes, AFAIK, GCC would assume paths that end up
a4462ff
calling the __init/__exit functions are not meant to be taken
a4462ff
(but when we are asked to load modules, that is the expected
a4462ff
path, no?).
a4462ff
a4462ff
I will put this in the compiler-attributes tree and get
a4462ff
some time in linux-next, unless you want to pick it up!
a4462ff
a4462ff
 include/linux/module.h | 4 ++--
a4462ff
 1 file changed, 2 insertions(+), 2 deletions(-)
a4462ff
a4462ff
diff --git a/include/linux/module.h b/include/linux/module.h
a4462ff
index 8fa38d3e7538..c4e805e87628 100644
a4462ff
--- a/include/linux/module.h
a4462ff
+++ b/include/linux/module.h
a4462ff
@@ -129,13 +129,13 @@ extern void cleanup_module(void);
a4462ff
 #define module_init(initfn)					\
a4462ff
 	static inline initcall_t __maybe_unused __inittest(void)		\
a4462ff
 	{ return initfn; }					\
a4462ff
-	int init_module(void) __attribute__((alias(#initfn)));
a4462ff
+	int init_module(void) __cold __attribute__((alias(#initfn)));
a4462ff
 
a4462ff
 /* This is only required if you want to be unloadable. */
a4462ff
 #define module_exit(exitfn)					\
a4462ff
 	static inline exitcall_t __maybe_unused __exittest(void)		\
a4462ff
 	{ return exitfn; }					\
a4462ff
-	void cleanup_module(void) __attribute__((alias(#exitfn)));
a4462ff
+	void cleanup_module(void) __cold __attribute__((alias(#exitfn)));
a4462ff
 
a4462ff
 #endif
a4462ff