From patchwork Sat Feb 9 00:08:38 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miguel Ojeda X-Patchwork-Id: 1040186 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF5ACC169C4 for ; Sat, 9 Feb 2019 00:09:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B6A22177B for ; Sat, 9 Feb 2019 00:09:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fBDNHARm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726847AbfBIAJH (ORCPT ); Fri, 8 Feb 2019 19:09:07 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:35134 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726222AbfBIAJH (ORCPT ); Fri, 8 Feb 2019 19:09:07 -0500 Received: by mail-wm1-f66.google.com with SMTP id t200so6175302wmt.0 for ; Fri, 08 Feb 2019 16:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=oYZRhi80jnWf5lvJ9rxSq8k+5uIG9VwWaCu5KNmb2Io=; b=fBDNHARmMKhmm+ePaNJj9txjNbOdazSkbZWB/n5YjOQJiidCJgtPUkWYcWKtUsrySa trWv7EzzGxFKTM9ccHPDsc7WS8wtoOlUSU00LZPieepciKS24buQhuHPZFvVIRn+531E WXI4lpQh/8WxwUBQRjxoDJhdHoBt66E/f63atN5vJMnc3ThZSTsQ4Sfu52xF44sOuN/B TE10KX4vZtqb0SGWn2TObNYiAWh6hRVzo8h9o1Ako8t4KyfHIuMFlVsnHfG/afjhbNIN haKI0M5yLUxjlEGqljgCH6x51eoDN5o5GVzckrZ1zUZDuRe5854+1nj6iZ4SKOFLM5/t hg6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=oYZRhi80jnWf5lvJ9rxSq8k+5uIG9VwWaCu5KNmb2Io=; b=EaydbtrOBjU5ArDWvIEICz9CCbooh+J6TlXBqzt2APusJL1ADHL7AiL3IFoZYivKAy dLXHrxdC+hMc+C0rufUF1wvkTxF6SPYKcJTAUvfCoH1wkqarOXxObgmGmjeijAuUz288 VjD5hgExmBvZ+o66edIlkKQJsAWsIuDqXusyYilSoN5QYBYSBmB530Y2yfX+6gXM5Tn7 9ZrYp/qiujklOWITA1apRD4MMpP2b3P32zxvG/HzP33sm4EZVf935TaUlcjJkan7UqIs ycdaD3KcYyiAbxn6hv0RrFV+bX2V7IaurX3cnF5iGt12WTYOtC2UizjA9vjC6Ns2zS+1 uejQ== X-Gm-Message-State: AHQUAuY6BHyRa9wiG2h1k9f9xax3Up2BqnNZu3xueFVVQc0q4ArgMZlr s+LA0mz9JF3YQMPyfq9jGdJkNupaJ8fp5g== X-Google-Smtp-Source: AHgI3IbP7F6OnN6J3jwdNsAPLLKsA8GObtlao2W2lxU4EKIzxT9TvoA9f9ljD5W+YZ8ax1/9FCi/xw== X-Received: by 2002:adf:f487:: with SMTP id l7mr531117wro.86.1549670944704; Fri, 08 Feb 2019 16:09:04 -0800 (PST) Received: from localhost.localdomain (79.108.96.12.dyn.user.ono.com. [79.108.96.12]) by smtp.gmail.com with ESMTPSA id 65sm10483171wrb.62.2019.02.08.16.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 16:09:04 -0800 (PST) From: Miguel Ojeda To: linux-kernel@vger.kernel.org Cc: Miguel Ojeda , Laura Abbott , Martin Sebor , Arnd Bergmann , Herbert Xu , Ard Biesheuvel , Krzysztof Kozlowski , Catalin Marinas Subject: [PATCH 1/3] lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as __pure Date: Sat, 9 Feb 2019 01:08:38 +0100 Message-Id: <20190209000840.11018-2-miguel.ojeda.sandonis@gmail.com> In-Reply-To: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 here because crc32_le_base/__crc32c_le_base aren't __pure while their target crc32_le/__crc32c_le are. These aliases are used by architectures as a fallback in accelerated versions of CRC32. See commit 9784d82db3eb ("lib/crc32: make core crc32() routines weak so they can be overridden"). Therefore, being fallbacks, it is likely that even if the aliases were called from C, there wouldn't be any optimizations possible. Currently, the only user is arm64, which calls this from asm. Still, marking the aliases as __pure makes sense and is a good idea for documentation purposes and possible future optimizations, which also silences the warning. Acked-by: Ard Biesheuvel Tested-by: Laura Abbott Signed-off-by: Miguel Ojeda --- lib/crc32.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/crc32.c b/lib/crc32.c index 45b1d67a1767..4a20455d1f61 100644 --- a/lib/crc32.c +++ b/lib/crc32.c @@ -206,8 +206,8 @@ u32 __pure __weak __crc32c_le(u32 crc, unsigned char const *p, size_t len) EXPORT_SYMBOL(crc32_le); EXPORT_SYMBOL(__crc32c_le); -u32 crc32_le_base(u32, unsigned char const *, size_t) __alias(crc32_le); -u32 __crc32c_le_base(u32, unsigned char const *, size_t) __alias(__crc32c_le); +u32 __pure crc32_le_base(u32, unsigned char const *, size_t) __alias(crc32_le); +u32 __pure __crc32c_le_base(u32, unsigned char const *, size_t) __alias(__crc32c_le); /* * This multiplies the polynomials x and y modulo the given modulus. From patchwork Sat Feb 9 00:08:39 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Miguel Ojeda X-Patchwork-Id: 1040187 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06134C282CC for ; Sat, 9 Feb 2019 00:09:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C797721841 for ; Sat, 9 Feb 2019 00:09:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MirIZ+3P" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726894AbfBIAJI (ORCPT ); Fri, 8 Feb 2019 19:09:08 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:52552 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726211AbfBIAJI (ORCPT ); Fri, 8 Feb 2019 19:09:08 -0500 Received: by mail-wm1-f65.google.com with SMTP id m1so6280200wml.2 for ; Fri, 08 Feb 2019 16:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=5ORFvEqPg40FyrMt/fLXHHlLvflq3laGk3IRwh/eP24=; b=MirIZ+3PsN5et4GxGn+L8yDCYRFmolz3ch2quRams1L4kezKyKP8T1h/lMWw4HLw3j qflJWUF7dxCkRm9BZo5oB9P1g8LduJUF6eDllCAeVgX9Ucjiv9YL/CzuxxnMIcZCxhQ3 Cvaitucrcr2zoCbinGZJ3UTMc87z41zG++3beXvnGOW8yVGbD9SSsh+rnqC0zPT8/le6 ahFOr3X3hhXMequKxkYzpCl2B6rvjNHHKZAgHiWpfIFYdPXiNzw/ynmgjlE7d30YyEfJ lCUE9f2pQkLwezxuilWYIRJzGpL6oFcbp7tncmhyw08pUI8DI/2BLVSq39ygOuxSXs+N Yz5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=5ORFvEqPg40FyrMt/fLXHHlLvflq3laGk3IRwh/eP24=; b=VJIGQ/B70+kuZ0LEtdZ+dy4ex6I17bzPvCety3qDUtq1XpARIvFjmxjYdoXNPjbPpz ma7ZZvXNVeDUTgAd2flnsyjzk9RMNokT2w7YWltBGZgiNxoPzrobHKhLyfdjUWgjo5FH bHuUDJKAf6EMFUiMcWbgvXA7PTLvF2kZ0b9Sm5n+pViOQcdu6lHSbWb8nJgCcyoHNf0v 2Yv+wtop89bM3YkbE/pCq5XIepi6Po4gnmlmlRxrhGQ6/GWGcaxX2UeEb6nEXaQAXMjB AwlzqzcATrbX6OFKYyfYv15g4ZRqHneZxyQPz76ntnlTqoDmZyFaD2sbLHb4ca50WqEX ZXJw== X-Gm-Message-State: AHQUAuamoKJjvGO/OyguJDIQG1W8Frj/lI1c6vr8G/4NidoSHwrlsusG k2VpBk2l8HS/ovAHysacldfMzUN77xdVvg== X-Google-Smtp-Source: AHgI3IYsXZWonq/T/Yz16YT3iZm6Rkmn7EyPr0s0FcW+a9bKEfN4EiUiDsqJUDrfOy02pYl4uzpiQA== X-Received: by 2002:adf:ca13:: with SMTP id o19mr18202139wrh.148.1549670946088; Fri, 08 Feb 2019 16:09:06 -0800 (PST) Received: from localhost.localdomain (79.108.96.12.dyn.user.ono.com. [79.108.96.12]) by smtp.gmail.com with ESMTPSA id 65sm10483171wrb.62.2019.02.08.16.09.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 16:09:05 -0800 (PST) From: Miguel Ojeda To: linux-kernel@vger.kernel.org Cc: Miguel Ojeda , Martin Sebor , Arnd Bergmann , Laura Abbott , Nick Desaulniers , Luc Van Oostenryck , Andrey Konovalov , Kees Cook , Sean Christopherson Subject: [PATCH 2/3] Compiler Attributes: add support for __copy (gcc >= 9) Date: Sat, 9 Feb 2019 01:08:39 +0100 Message-Id: <20190209000840.11018-3-miguel.ojeda.sandonis@gmail.com> In-Reply-To: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From the GCC manual: copy copy(function) The copy attribute applies the set of attributes with which function has been declared to the declaration of the function to which the attribute is applied. The attribute is designed for libraries that define aliases or function resolvers that are expected to specify the same set of attributes as their targets. The copy attribute can be used with functions, variables, or types. However, the kind of symbol to which the attribute is applied (either function or variable) must match the kind of symbol to which the argument refers. The copy attribute copies only syntactic and semantic attributes but not attributes that affect a symbol’s linkage or visibility such as alias, visibility, or weak. The deprecated attribute is also not copied. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html 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, e.g.: void __cold f(void) {} void __alias("f") g(void); diagnoses: warning: 'g' specifies less restrictive attribute than its target 'f': 'cold' [-Wmissing-attributes] Using __copy(f) we can copy the __cold attribute from f to g: void __cold f(void) {} void __copy(f) __alias("f") g(void); This attribute is most useful to deal with situations where an alias is declared but we don't know the exact attributes the target has. For instance, in the kernel, the widely used module_init/exit macros define the init/cleanup_module aliases, but those cannot be marked always as __init/__exit since they some modules do not have their functions marked as such. Suggested-by: Martin Sebor Signed-off-by: Miguel Ojeda Reviewed-by: Nick Desaulniers --- include/linux/compiler_attributes.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/include/linux/compiler_attributes.h b/include/linux/compiler_attributes.h index 19f32b0c29af..6b318efd8a74 100644 --- a/include/linux/compiler_attributes.h +++ b/include/linux/compiler_attributes.h @@ -34,6 +34,7 @@ #ifndef __has_attribute # define __has_attribute(x) __GCC4_has_attribute_##x # define __GCC4_has_attribute___assume_aligned__ (__GNUC_MINOR__ >= 9) +# define __GCC4_has_attribute___copy__ 0 # define __GCC4_has_attribute___designated_init__ 0 # define __GCC4_has_attribute___externally_visible__ 1 # define __GCC4_has_attribute___noclone__ 1 @@ -100,6 +101,19 @@ */ #define __attribute_const__ __attribute__((__const__)) +/* + * Optional: only supported since gcc >= 9 + * Optional: not supported by clang + * Optional: not supported by icc + * + * gcc: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-copy-function-attribute + */ +#if __has_attribute(__copy__) +# define __copy(symbol) __attribute__((__copy__(symbol))) +#else +# define __copy(symbol) +#endif + /* * Don't. Just don't. See commit 771c035372a0 ("deprecate the '__deprecated' * attribute warnings entirely and for good") for more information. From patchwork Sat Feb 9 00:08:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miguel Ojeda X-Patchwork-Id: 1040188 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32DFBC4151A for ; Sat, 9 Feb 2019 00:09:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F415A2177B for ; Sat, 9 Feb 2019 00:09:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fnSxCEl/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726952AbfBIAJK (ORCPT ); Fri, 8 Feb 2019 19:09:10 -0500 Received: from mail-wm1-f67.google.com ([209.85.128.67]:37227 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726222AbfBIAJJ (ORCPT ); Fri, 8 Feb 2019 19:09:09 -0500 Received: by mail-wm1-f67.google.com with SMTP id x10so824565wmg.2 for ; Fri, 08 Feb 2019 16:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=yxdwW1DyOtKem0WF782kU0A9egQwo4Qvb/PrColHLsc=; b=fnSxCEl/bREIP3RAd8NIp5N+R5sUUw7aoHfWroXeUgHAbdmejiO7oc5wXLAEpd6Cyp 8XcURtp1dY/UuFEsajmGDsm1LkrPE4I1ktUNwpanSsFo2g1ULWf1wKXBOWLcQz96OHCO 6oiWOvAOyiYggXqmUIY0QmCgVEPeHbqi2NhAxrfHPw5K2iIyg6eJdlLjheNZQe4cLR// H3LdjPgINUDp5Y9qXSw9RThVXi/2m4QX1NSRVkcYrMqmMrksKSnIEPmCVY2DZh+IgXpd 74G4pIpPNLg0jSx3uYpwyCYpxjFmm6YtPJU4ZuGrEPQpoSyyUFzIWYBe5q/zMDPztB2k K8LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=yxdwW1DyOtKem0WF782kU0A9egQwo4Qvb/PrColHLsc=; b=qL21kr4jTNpUZHGZD8TyHhmvC5NRGgE9y5IPFZE3B5xdL0qXg0QO1v/EaOgcJOBKxl IBiKPeG3mVZyegERqZ97HKpql3G9ZO5wLcJTChAYGS8nR/XkJrXsK8ZXkGoG2aVcMxtO lFrflsQtbHrCZZbdhgoYJAYpT9oDRWzi1I8px5OugXDFY9Bbf8zl9ASW+FS2OYDNpcIp 8SEnQoVP+ZZrhGbni/RJWmuXZjvahkEPE4hRG9AKgtH3GjUbMZNRFqmEa34kS0hyq2g8 6W2AzI4TqAzXXpL+uMH7eBYsTO3l5/CGqq8LcnKY6yEfIgJV3ktPHv+p97VPwPTRCt/3 ssIA== X-Gm-Message-State: AHQUAub5NqVrELwrJIP8cP/Vg6X05+ZcDkdfa2wGjXecLMafbzXuXQ0T 7htXMP3NJ7Ag3oZrUsS7nlE= X-Google-Smtp-Source: AHgI3IaZloQG5Jl9/hr4QFOoadP0GpzDuRvYrquOnSQlqZ+xi9CGKN8cYjJa7a//JZ7KkKCUdA/4mw== X-Received: by 2002:a7b:c4cb:: with SMTP id g11mr742497wmk.149.1549670947426; Fri, 08 Feb 2019 16:09:07 -0800 (PST) Received: from localhost.localdomain (79.108.96.12.dyn.user.ono.com. [79.108.96.12]) by smtp.gmail.com with ESMTPSA id 65sm10483171wrb.62.2019.02.08.16.09.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 16:09:06 -0800 (PST) From: Miguel Ojeda To: Jessica Yu Cc: Miguel Ojeda , Laura Abbott , Martin Sebor , Arnd Bergmann , Masahiro Yamada , James Morris , Mathieu Desnoyers , Borislav Petkov , Kees Cook , Matt Mullins , Vincent Whitchurch , WANG Chao , 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 Message-Id: <20190209000840.11018-4-miguel.ojeda.sandonis@gmail.com> In-Reply-To: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> References: <20190209000840.11018-1-miguel.ojeda.sandonis@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Signed-off-by: Miguel Ojeda --- 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