ngompa/kernel-rpm
1
0
Fork 0
forked from rpms/kernel
Code Pull Requests Activity

Linux v5.0-rc6

Browse Source 
Tweaks to gcc9 fixes
This commit is contained in:
Laura Abbott 2019-02-11 06:16:56 -08:00
parent 76c7367ad0
commit 4e4f5c72ef
8 changed files with 520 additions and 211 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

93
0001-s390-jump_label-Correct-asm-contraint.patch
View File

@ -1,50 +1,63 @@
From dc6aae3ea5041f47d2445ba2ce086f9e8679861e Mon Sep 17 00:00:00 2001
From: Laura Abbott <labbott@redhat.com>
Date: Wed, 23 Jan 2019 13:50:24 +0100
From b0b46a5b622fdbe69207675c5d50b77cb8ae43b7 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Tue, 5 Feb 2019 13:43:49 +0100
Subject: [PATCH] s390/jump_label: Correct asm contraint
To: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-s390@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
There's a build failure with gcc9:
On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
> On 1/23/19 5:24 AM, Heiko Carstens wrote:
> >On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
> >>There's a build failure with gcc9:
> >>
> >> ./arch/s390/include/asm/jump_label.h: Assembler messages:
> >> ./arch/s390/include/asm/jump_label.h:23: Error: bad expression
> >> ./arch/s390/include/asm/jump_label.h:23: Error: junk at end of line, first unrecognized character is `r'
> >> make[1]: *** [scripts/Makefile.build:277: init/main.o] Error 1
...
> I've had to turn off s390 in Fedora until this gets fixed :(
./arch/s390/include/asm/jump_label.h: Assembler messages:
./arch/s390/include/asm/jump_label.h:23: Error: bad expression
./arch/s390/include/asm/jump_label.h:23: Error: junk at end of line, first unrecognized character is `r'
make[1]: *** [scripts/Makefile.build:277: init/main.o] Error 1
Laura, the patch below should fix this (temporarily). If possible,
could you give it a try? It seems to work for me.
According to the toolchain people, the actual issue is the use of
"X" constraint which is too permissive. Switch to using "i" instead.
rom 4067027c2ccc8d3f1dc3bb19fe2d00da0c65bcd8 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Date: Tue, 5 Feb 2019 13:21:56 +0100
Subject: [PATCH] s390: disable section anchors
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1668703
Signed-off-by: Laura Abbott <labbott@redhat.com>
Disable section anchors to allow to compile with the current gcc 9
experimental version. The section anchors is a new feature for s390
with gcc 9, however it breaks our current usage of the 'X' constraint
within the asm goto construct within our jump label implementation.
Fixing this seems to be non-trivial, therefore (hopefully) temporarily
disable section anchors. We will hopefully have a better solution
before gcc 9 is released, so that this can be removed again.
Reported-by: Laura Abbott <labbott@redhat.com>
Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
arch/s390/include/asm/jump_label.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
arch/s390/Makefile | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
index e2d3e6c43395..41dabfd8518d 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -22,7 +22,7 @@ static inline bool arch_static_branch(struct static_key *key, bool branch)
".long 0b-.,%l[label]-.\n"
".quad %0-.\n"
".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
+ : : "i" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
@@ -36,7 +36,7 @@ static inline bool arch_static_branch_jump(struct static_key *key, bool branch)
".long 0b-.,%l[label]-.\n"
".quad %0-.\n"
".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
+ : : "i" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index e21053e5e0da..1eac75bc3a29 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -62,6 +62,14 @@ cflags-y += -Wa,-I$(srctree)/arch/$(ARCH)/include
#
cflags-$(CONFIG_FRAME_POINTER) += -fno-optimize-sibling-calls
+#
+# Disable section anchors. This gcc 9 feature currently breaks the 'X'
+# constraint like it is used in the asm goto construct.
+#
+ifeq ($(call cc-option-yn,-fno-section-anchors),y)
+cflags-y += -fno-section-anchors
+endif
+
ifeq ($(call cc-option-yn,-mpacked-stack),y)
cflags-$(CONFIG_PACK_STACK) += -mpacked-stack -D__PACK_STACK
aflags-$(CONFIG_PACK_STACK) += -D__PACK_STACK
--
2.20.1

450
Clean-the-new-GCC-9--Wmissing-attributes-warnings.patch Normal file
View File

@ -0,0 +1,450 @@
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 <miguel.ojeda.sandonis@gmail.com>
X-Patchwork-Id: 1040186
Return-Path: <SRS0=1U6d=QQ=vger.kernel.org=linux-kernel-owner@kernel.org>
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id CF5ACC169C4
for <linux-kernel@archiver.kernel.org>; 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 <linux-kernel@archiver.kernel.org>; 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
<rfc822;linux-kernel@archiver.kernel.org>);
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
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 8 Feb 2019 19:09:07 -0500
Received: by mail-wm1-f66.google.com with SMTP id t200so6175302wmt.0
for <linux-kernel@vger.kernel.org>;
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 <miguel.ojeda.sandonis@gmail.com>
To: linux-kernel@vger.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>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
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: <linux-kernel.vger.kernel.org>
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 <ard.biesheuvel@linaro.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
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 <miguel.ojeda.sandonis@gmail.com>
X-Patchwork-Id: 1040187
Return-Path: <SRS0=1U6d=QQ=vger.kernel.org=linux-kernel-owner@kernel.org>
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id 06134C282CC
for <linux-kernel@archiver.kernel.org>; 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 <linux-kernel@archiver.kernel.org>; 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
<rfc822;linux-kernel@archiver.kernel.org>);
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
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 8 Feb 2019 19:09:08 -0500
Received: by mail-wm1-f65.google.com with SMTP id m1so6280200wml.2
for <linux-kernel@vger.kernel.org>;
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 <miguel.ojeda.sandonis@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Martin Sebor <msebor@gcc.gnu.org>,
Arnd Bergmann <arnd@arndb.de>,
Laura Abbott <labbott@redhat.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Andrey Konovalov <andreyknvl@google.com>,
Kees Cook <keescook@chromium.org>,
Sean Christopherson <sean.j.christopherson@intel.com>
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: <linux-kernel.vger.kernel.org>
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 <msebor@gcc.gnu.org>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
---
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 <miguel.ojeda.sandonis@gmail.com>
X-Patchwork-Id: 1040188
Return-Path: <SRS0=1U6d=QQ=vger.kernel.org=linux-kernel-owner@kernel.org>
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
by smtp.lore.kernel.org (Postfix) with ESMTP id 32DFBC4151A
for <linux-kernel@archiver.kernel.org>; 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 <linux-kernel@archiver.kernel.org>; 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
<rfc822;linux-kernel@archiver.kernel.org>);
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
<rfc822;linux-kernel@vger.kernel.org>);
Fri, 8 Feb 2019 19:09:09 -0500
Received: by mail-wm1-f67.google.com with SMTP id x10so824565wmg.2
for <linux-kernel@vger.kernel.org>;
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 <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
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: <linux-kernel.vger.kernel.org>
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 <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
configs/fedora/generic/s390x/CONFIG_JUMP_LABEL
View File

@ -1 +1 @@
# CONFIG_JUMP_LABEL is not set
CONFIG_JUMP_LABEL=y

2
kernel-s390x-debug.config
View File

@ -2340,7 +2340,7 @@ CONFIG_JOYSTICK_XPAD_LEDS=y
CONFIG_JOYSTICK_XPAD=m
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JSA1212 is not set
# CONFIG_JUMP_LABEL is not set
CONFIG_JUMP_LABEL=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS=y
CONFIG_KARMA_PARTITION=y

2
kernel-s390x.config
View File

@ -2323,7 +2323,7 @@ CONFIG_JOYSTICK_XPAD_LEDS=y
CONFIG_JOYSTICK_XPAD=m
CONFIG_JOYSTICK_ZHENHUA=m
# CONFIG_JSA1212 is not set
# CONFIG_JUMP_LABEL is not set
CONFIG_JUMP_LABEL=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS=y
CONFIG_KARMA_PARTITION=y

20
kernel.spec
View File

@ -69,7 +69,7 @@ Summary: The Linux kernel
# Work around for major version bump
%define upstream_sublevel 0
# The rc snapshot level
%global rcrev 5
%global rcrev 6
# The git snapshot level
%define gitrev 0
# Set rpm version accordingly
@ -428,7 +428,7 @@ BuildRequires: binutils-%{_build_arch}-linux-gnu, gcc-%{_build_arch}-linux-gnu
%endif
# Source0: https://www.kernel.org/pub/linux/kernel/v5.x/linux-%{kversion}.tar.xz
Source0: https://git.kernel.org/torvalds/t/linux-5.0-rc5.tar.gz
Source0: https://git.kernel.org/torvalds/t/linux-5.0-rc6.tar.gz
Source11: x509.genkey
Source12: remove-binary-diff.pl
@ -576,9 +576,6 @@ Patch305: qcom-msm89xx-fixes.patch
# https://patchwork.kernel.org/project/linux-mmc/list/?submitter=71861
Patch306: arm-sdhci-esdhc-imx-fixes.patch
# https://patchwork.kernel.org/patch/10765783/
Patch307: wlcore-sdio-Fixup-power-on-off-sequence.patch
# https://patchwork.kernel.org/patch/10778815/
Patch308: drm-enable-uncached-DMA-optimization-for-ARM-and-arm64.patch
@ -605,8 +602,8 @@ Patch501: input-rmi4-remove-the-need-for-artifical-IRQ.patch
Patch504: efi-use-32-bit-alignment-for-efi_guid_t.patch
# gcc9 fixes
Patch505: include-linux-module.h-mark-init-cleanup_module-aliases-as-__cold.patch
Patch506: lib-crc32.c-mark-crc32_le_base-__crc32c_le_base-aliases-as-__pure.patch
Patch505: Clean-the-new-GCC-9--Wmissing-attributes-warnings.patch
Patch506: 0001-s390-jump_label-Correct-asm-contraint.patch
Patch507: 0001-Drop-that-for-now.patch
# patches for https://fedoraproject.org/wiki/Changes/FlickerFreeBoot
@ -1890,6 +1887,15 @@ fi
#
#
%changelog
* Mon Feb 11 2019 Laura Abbott <labbott@redhat.com> - 5.0.0-0.rc6.git0.1
- Linux v5.0-rc6
- Disable debugging options.
- Tweaks to gcc9 fixes
* Mon Feb 04 2019 Laura Abbott <labbott@redhat.com> - 5.0.0-0.rc5.git0.1
- Linux v5.0-rc5
- Disable debugging options.
* Fri Feb 01 2019 Laura Abbott <labbott@redhat.com> - 5.0.0-0.rc4.git3.1
- Linux v5.0-rc4-106-g5b4746a03199

1
sources
View File

@ -1 +1,2 @@
SHA512 (linux-5.0-rc5.tar.gz) = 02959a943550dec91b2b9a036a000acb62025ac9b2fe5c04900bdf32a3f39bd7460c91d7da20b9bb2ac70bcdde7d003822a2a752d39eb4e290a7138d861f5d8d
SHA512 (linux-5.0-rc6.tar.gz) = de3d6acf9282cfa831e87994df9c2cc855b43cd2638a6417888098e3ce54384780e67c8de0ca6a9163950808012bc4de28740e61c00d3337506d76da840d6ff5

161
wlcore-sdio-Fixup-power-on-off-sequence.patch
View File

@ -1,161 +0,0 @@
From patchwork Wed Jan 16 11:37:23 2019
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Patchwork-Submitter: Ulf Hansson <ulf.hansson@linaro.org>
X-Patchwork-Id: 10765783
Return-Path: <linux-omap-owner@kernel.org>
Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org
[172.30.200.125])
by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 956256C2
for <patchwork-linux-omap@patchwork.kernel.org>;
Wed, 16 Jan 2019 11:37:39 +0000 (UTC)
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])
by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 860D62D08C
for <patchwork-linux-omap@patchwork.kernel.org>;
Wed, 16 Jan 2019 11:37:39 +0000 (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486)
id 7A4732DBF8; Wed, 16 Jan 2019 11:37:39 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
pdx-wl-mail.web.codeaurora.org
X-Spam-Level:
X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI
autolearn=unavailable version=3.3.1
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 86DFA2D579
for <patchwork-linux-omap@patchwork.kernel.org>;
Wed, 16 Jan 2019 11:37:37 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S2389465AbfAPLhg (ORCPT
<rfc822;patchwork-linux-omap@patchwork.kernel.org>);
Wed, 16 Jan 2019 06:37:36 -0500
Received: from mail-lj1-f195.google.com ([209.85.208.195]:46058 "EHLO
mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S2389488AbfAPLhg (ORCPT
<rfc822;linux-omap@vger.kernel.org>); Wed, 16 Jan 2019 06:37:36 -0500
Received: by mail-lj1-f195.google.com with SMTP id s5-v6so5113775ljd.12
for <linux-omap@vger.kernel.org>;
Wed, 16 Jan 2019 03:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google;
h=from:to:cc:subject:date:message-id;
bh=G4uWfUBdfRWJ7ooa2ukqyMzWYVfm+tWSAZRULgvNQ08=;
b=DqdSNsfGTw5APfw140m3LimoqimPBt+dTkOxqu/2bQyXk7S9f23O7PxiN3oFynlZKr
SASxPUZ8sG4xbfOK9h8FHLlWWFpRIZSahu+mE0EseqtvBLV4sdCnBwOS8M3gko6ngb7C
i176BhDXn0+wm8tZGD3yN7Qp96KnQZ3Sv/tjk=
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;
bh=G4uWfUBdfRWJ7ooa2ukqyMzWYVfm+tWSAZRULgvNQ08=;
b=a7MooeHuGM0cTZPVwhtKcW1jg4pqdeIMk6f7/zUrRv+SoOb7Vnw9KEGP3KU5lDSMo5
fdJcqriPtpflqlW2b23HNJ2gVIYbySV3bmkiu2AKTwNWCFTkIS2ortWV4MES6WsAsR7G
SJBjNOxj2qAxl8qauqOq0X2TNOhKQXtXsfOZ+d5pkSB1+/BBEcxtWLRHwsnMQW5GjawC
DICSSEnG7V41Nz/GwJN/YMZ5mDDoTgm5E0w5FUpgIsWkaZ3EwXNfATg7MrYDRaaP8D+y
Bc3D5LBTeGf5Ka2znrkAwm5UNG0ACbfhyC051z0Pt/8c0dPIdccFOYiaQId02Kxg6z3K
O1Tw==
X-Gm-Message-State: AJcUukfOVkWnN7bzdpLCd5T4eBBp4b+eeSeNmP9oASomJxjWdmE2FFn/
FXErvZDhVCsQSfNn/eJnmK5Zq0rkuSY=
X-Google-Smtp-Source:
ALg8bN4GExvNSUhrn1ThdHo4TWGq9deM7EiNDhwBHUXk+6BhziaXs9EaV54O4+YG3vKLHV5hZLkJyg==
X-Received: by 2002:a2e:6503:: with SMTP id
z3-v6mr6194730ljb.153.1547638653812;
Wed, 16 Jan 2019 03:37:33 -0800 (PST)
Received: from localhost.localdomain (h-158-174-22-210.NA.cust.bahnhof.se.
[158.174.22.210])
by smtp.gmail.com with ESMTPSA id
f11sm1144237lfi.12.2019.01.16.03.37.32
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 16 Jan 2019 03:37:33 -0800 (PST)
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Kalle Valo <kvalo@codeaurora.org>,
Tony Lindgren <tony@atomide.com>, Eyal Reizer <eyalr@ti.com>,
linux-wireless@vger.kernel.org
Cc: Ricardo Salveti <rsalveti@rsalveti.net>,
Kishon Vijay Abraham I <kishon@ti.com>,
Anders Roxell <anders.roxell@linaro.org>,
John Stultz <john.stultz@linaro.org>,
Jan Kiszka <jan.kiszka@web.de>,
Ulf Hansson <ulf.hansson@linaro.org>,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: [PATCH V2] wlcore: sdio: Fixup power on/off sequence
Date: Wed, 16 Jan 2019 12:37:23 +0100
Message-Id: <20190116113723.15668-1-ulf.hansson@linaro.org>
X-Mailer: git-send-email 2.17.1
Sender: linux-omap-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-omap.vger.kernel.org>
X-Mailing-List: linux-omap@vger.kernel.org
X-Virus-Scanned: ClamAV using ClamSMTP
During "wlan-up", we are programming the FW into the WiFi-chip. However,
re-programming the FW doesn't work, unless a power cycle of the WiFi-chip
is made in-between the programmings.
To conform to this requirement and to fix the regression in a simple way,
let's start by allowing that the SDIO card (WiFi-chip) may stay powered on
(runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the
current code is to treat this scenario as an error, but unfortunate this
doesn't work as expected, so let's fix this.
The other part is to guarantee that a power cycle of the SDIO card has been
completed when wl12xx_sdio_power_on() returns, as to allow the FW
programming to succeed. However, relying solely on runtime PM to deal with
this isn't sufficient. For example, userspace may prevent runtime suspend
via sysfs for the device that represents the SDIO card, leading to that the
mmc core also keeps it powered on. For this reason, let's instead do a
brute force power cycle in wl12xx_sdio_power_on().
Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
Changes in v2:
- Keep the SDIO host claimed when calling mmc_hw_reset().
- Add a fixes tag.
---
drivers/net/wireless/ti/wlcore/sdio.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index bd10165d7eec..4d4b07701149 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -164,6 +164,12 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue)
}
sdio_claim_host(func);
+ /*
+ * To guarantee that the SDIO card is power cycled, as required to make
+ * the FW programming to succeed, let's do a brute force HW reset.
+ */
+ mmc_hw_reset(card->host);
+
sdio_enable_func(func);
sdio_release_host(func);
@@ -174,20 +180,13 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
{
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
- int error;
sdio_claim_host(func);
sdio_disable_func(func);
sdio_release_host(func);
/* Let runtime PM know the card is powered off */
- error = pm_runtime_put(&card->dev);
- if (error < 0 && error != -EBUSY) {
- dev_err(&card->dev, "%s failed: %i\n", __func__, error);
-
- return error;
- }
-
+ pm_runtime_put(&card->dev);
return 0;
}