From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE01BC0650F for ; Mon, 5 Aug 2019 13:16:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7DE6B20679 for ; Mon, 5 Aug 2019 13:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565010988; bh=+5Js5A2JtGGZrWLC2jdZDIp+gwKVT9ufZ+BqhvtRjBw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=NjJeEqhEmIeN36LS6oZ8u0x6bpqZ1vU2AfAXxGPIO2yhXksRA0cStiqY/cVPpn4PW S5l8fE6YD6XHdvrDsArZAPWUp+IifFNCbE3E45pH+j1oLEMVb2dDXPnn6/WGxc9NHv EfsJzc7fP0Tj3BuB2WmQBNycCYdxyUbpDffqLh14= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729830AbfHENQ1 (ORCPT ); Mon, 5 Aug 2019 09:16:27 -0400 Received: from mail.kernel.org ([198.145.29.99]:42704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729524AbfHENGM (ORCPT ); Mon, 5 Aug 2019 09:06:12 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3C83D206C1; Mon, 5 Aug 2019 13:06:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565010371; bh=+5Js5A2JtGGZrWLC2jdZDIp+gwKVT9ufZ+BqhvtRjBw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2FY2gHIbbnEI0ad7CiBWItPUQum5Be/301esA0/qJNe1ajKIUvG5vwr6w6G9qgb4J qmQJ5rsmzPbHQr5zdaoQvQBNkRVwNOSefotpV7cl6un50yIXNvM6M4u+VtTcL1vwYA CG2XRFTiOCGU17Wrl7IlFebv0g3PCOaKYywO4ru0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "stable@vger.kernel.org, Miguel Ojeda" , Martin Sebor , Jessica Yu , Miguel Ojeda Subject: [PATCH 4.9 40/42] include/linux/module.h: copy __init/__exit attrs to init/cleanup_module Date: Mon, 5 Aug 2019 15:03:06 +0200 Message-Id: <20190805124929.717616311@linuxfoundation.org> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190805124924.788666484@linuxfoundation.org> References: <20190805124924.788666484@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Miguel Ojeda commit a6e60d84989fa0e91db7f236eda40453b0e44afa upstream. 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/259986242.BvXPX32bHu@devpool35/ Cc: Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/ Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/ Suggested-by: Martin Sebor Acked-by: Jessica Yu Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman --- include/linux/module.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- 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