Actually get building with gcc9

s390 is still failing to build so exclude it for now.
Also bring in some fixes to clean up the warnings.
(Two that should be accepted upstream, one that needs
a closer look)

4 files changed, 302 insertions, 4 deletions

diff --git a/0001-Drop-that-for-now.patch b/0001-Drop-that-for-now.patch
new file mode 100644
index 000000000..6419d9d9a
--- /dev/null
+++ b/0001-Drop-that-for-now.patch
@@ -0,0 +1,25 @@
+From 12cec6680e67d6b4fed9e30cd8c1f13871996cc1 Mon Sep 17 00:00:00 2001
+From: Laura Abbott <labbott@redhat.com>
+Date: Wed, 23 Jan 2019 14:36:37 +0100
+Subject: [PATCH] Drop that for now
+
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index f5b1d0d168e0..5f31107b22d1 100644
+--- a/Makefile
++++ b/Makefile
+@@ -430,7 +430,7 @@ KBUILD_AFLAGS   := -D__ASSEMBLY__ -fno-PIE
+ KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
+ 		   -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
+ 		   -Werror-implicit-function-declaration -Werror=implicit-int \
+-		   -Wno-format-security \
++		   -Wno-format-security -Wno-address-of-packed-member \
+ 		   -std=gnu89
+ KBUILD_CPPFLAGS := -D__KERNEL__
+ KBUILD_AFLAGS_KERNEL :=
+-- 
+2.20.1
+
diff --git a/include-linux-module.h-mark-init-cleanup_module-aliases-as-__cold.patch b/include-linux-module.h-mark-init-cleanup_module-aliases-as-__cold.patch
new file mode 100644
index 000000000..f350e6f32
--- /dev/null
+++ b/include-linux-module.h-mark-init-cleanup_module-aliases-as-__cold.patch
@@ -0,0 +1,149 @@
+From patchwork Wed Jan 23 17:37:07 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: 1034989
+Return-Path: <SRS0=drEb=P7=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 A7D50C282C0
+	for <linux-kernel@archiver.kernel.org>; Wed, 23 Jan 2019 17:38:31 +0000 (UTC)
+Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
+	by mail.kernel.org (Postfix) with ESMTP id 7CE1F20870
+	for <linux-kernel@archiver.kernel.org>; Wed, 23 Jan 2019 17:38:31 +0000 (UTC)
+Authentication-Results: mail.kernel.org;
+	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
+ header.b="qdRA7oPl"
+Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
+        id S1726152AbfAWRi3 (ORCPT
+        <rfc822;linux-kernel@archiver.kernel.org>);
+        Wed, 23 Jan 2019 12:38:29 -0500
+Received: from mail-wm1-f67.google.com ([209.85.128.67]:52719 "EHLO
+        mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
+        with ESMTP id S1725896AbfAWRi3 (ORCPT
+        <rfc822;linux-kernel@vger.kernel.org>);
+        Wed, 23 Jan 2019 12:38:29 -0500
+Received: by mail-wm1-f67.google.com with SMTP id m1so242485wml.2
+        for <linux-kernel@vger.kernel.org>;
+ Wed, 23 Jan 2019 09:38:27 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=gmail.com; s=20161025;
+        h=date:from:to:cc:subject:message-id:mime-version:content-disposition
+         :user-agent;
+        bh=1joVTuHcQFv5PhIFvZBlpu1jeKwRQi2Ty1HKsqzNx+0=;
+        b=qdRA7oPloipduZyiYE/EECaW/vCZup5EXmE5a1XgE9mc55H+TTPNNRTt44QJbQgbnn
+         wTNksIkBx8Gs0k3pJI9QIDO2J5AipLN8OOoxkPiDIJtAC8buHzQrdTxFG/4Uxw7tRf8X
+         A6PNyuUGr+02itkYIlALzEuDHvZna8yZx0zCeCDXF2IrGt0NBHZVTzz1XfX8LeQlCh9L
+         hleyVdDQnDvwxA7dXqrA4UugXUlEqT8HnIAUdg8+/xubsXOSz9T/22+zc9pZ9uSHm2uq
+         DpO/hgx1e5DONDN8T+sjjKCO0LnJ8Z9ZS0Huf+8W2XH1uxo48jSgXUOsygPQ36+8R/7t
+         ng6Q==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=1e100.net; s=20161025;
+        h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
+         :content-disposition:user-agent;
+        bh=1joVTuHcQFv5PhIFvZBlpu1jeKwRQi2Ty1HKsqzNx+0=;
+        b=ZQrXdTIYsCSUGNJS1C0dn+gibvoSHb2o+kcUMGTbH6G2tag3Zy4vnfIcBT0xhmvPLq
+         5pU8jskcufXp0qQ0sivNsBpJYJCbsqqiChoivTs9WC4rxoM5G62Wi0pAZL59fGGDnmyV
+         xjSTkSoxe8CiB+26BDzg52zkynkWC2v0OHgaM7/1lTeTqNxdYIvQ+hC4LXdy40bAP64/
+         JIC1nET+KwewpPHJQc2u87ah4xp6nEjzO/4wTP3CUi4zbZPTU17oH007IAXhObL7JO0r
+         XkRBJAgpcTKexfAJB7HnAUc4KLSv5L5Uz+Z14TusskTuK6njE11PE9GSJ7Z7lqufqJNZ
+         Z4GQ==
+X-Gm-Message-State: AJcUukdaW+EjUkHLIrpaLWRYCoF9XYWdpSiPfNnJgu3VB9CW8t9xYlZJ
+        NDU6hJ2AXvnDR+awfdjm6IU=
+X-Google-Smtp-Source: 
+ ALg8bN59XklA0HTVEDaLFI+8dguNdipIQWTlgIi23N78PjaLBzniLMXowf2nCpIra7boIidjtFvfYg==
+X-Received: by 2002:a1c:7c05:: with SMTP id x5mr3525198wmc.54.1548265106544;
+        Wed, 23 Jan 2019 09:38:26 -0800 (PST)
+Received: from gmail.com (79.108.96.12.dyn.user.ono.com. [79.108.96.12])
+        by smtp.gmail.com with ESMTPSA id
+ r77sm74200791wmd.22.2019.01.23.09.38.25
+        (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
+        Wed, 23 Jan 2019 09:38:25 -0800 (PST)
+Date: Wed, 23 Jan 2019 18:37:07 +0100
+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
+Message-ID: <20190123173707.GA16603@gmail.com>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+User-Agent: elm/2
+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 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
+ 
diff --git a/kernel.spec b/kernel.spec
index 76fdf35a5..191fee1fa 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -329,7 +329,7 @@ Summary: The Linux kernel
 # Which is a BadThing(tm).
 
 # We only build kernel-headers on the following...
-%define nobuildarches i386
+%define nobuildarches i386 s390x
 
 %ifarch %nobuildarches
 %define with_up 0
@@ -602,9 +602,9 @@ Patch501: input-rmi4-remove-the-need-for-artifical-IRQ.patch
 Patch504: efi-use-32-bit-alignment-for-efi_guid_t.patch
 
 # gcc9 fixes
-Patch505: 0001-Correct-warning-with-gcc9.patch
-Patch506: 0001-s390-jump_label-Correct-asm-contraint.patch
-
+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
+Patch507: 0001-Drop-that-for-now.patch
 
 # END OF PATCH DEFINITIONS
 
diff --git a/lib-crc32.c-mark-crc32_le_base-__crc32c_le_base-aliases-as-__pure.patch b/lib-crc32.c-mark-crc32_le_base-__crc32c_le_base-aliases-as-__pure.patch
new file mode 100644
index 000000000..2010603f4
--- /dev/null
+++ b/lib-crc32.c-mark-crc32_le_base-__crc32c_le_base-aliases-as-__pure.patch
@@ -0,0 +1,124 @@
+From patchwork Thu Jan 24 15:44:20 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: 1035252
+Return-Path: <SRS0=jJS3=QA=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 95925C282C3
+	for <linux-kernel@archiver.kernel.org>; Thu, 24 Jan 2019 15:44:28 +0000 (UTC)
+Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
+	by mail.kernel.org (Postfix) with ESMTP id 6368521872
+	for <linux-kernel@archiver.kernel.org>; Thu, 24 Jan 2019 15:44:28 +0000 (UTC)
+Authentication-Results: mail.kernel.org;
+	dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
+ header.b="DEOxuN9k"
+Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
+        id S1728590AbfAXPo1 (ORCPT
+        <rfc822;linux-kernel@archiver.kernel.org>);
+        Thu, 24 Jan 2019 10:44:27 -0500
+Received: from mail-wm1-f68.google.com ([209.85.128.68]:37788 "EHLO
+        mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
+        with ESMTP id S1727649AbfAXPo0 (ORCPT
+        <rfc822;linux-kernel@vger.kernel.org>);
+        Thu, 24 Jan 2019 10:44:26 -0500
+Received: by mail-wm1-f68.google.com with SMTP id g67so3548002wmd.2
+        for <linux-kernel@vger.kernel.org>;
+ Thu, 24 Jan 2019 07:44:25 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=gmail.com; s=20161025;
+        h=date:from:to:cc:subject:message-id:mime-version:content-disposition
+         :user-agent;
+        bh=JeyLhzrsCRzzO/4nbb0LJSQxILVpgC++VcQqugacalc=;
+        b=DEOxuN9kV3A3qQ3ere0UjnfgT3DE1Gc4z/52Qty46F/mbpPja2OkXvtPJ15RK9/h4Z
+         AG1fdkKf/GjCRaBidO9BLWwcoq0uiTV69J0KR0rF67QR9zxgGVEl8fu6s/ZmtKnnIdF4
+         AysPfOHY+/MwlcB6UOzADtS69SDUYTsxDxOfHBj/FjnS7WmNetq8ae17VvRdpd/JEWtE
+         M58OhgBYmckFYuVXQTEEhpm8w6TIefPA5S3r3KeUuXclMeqJ07pU1vJWK7tdTp7sIeAv
+         xYgGq49/NBPkUl4l+LdwVBwp+o6pvUfh2w9zBQW67xZu6rn/j500BV8xdubxQqHTauSM
+         oQPw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=1e100.net; s=20161025;
+        h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version
+         :content-disposition:user-agent;
+        bh=JeyLhzrsCRzzO/4nbb0LJSQxILVpgC++VcQqugacalc=;
+        b=twekOdboep908h8e5de5qIQIgDuUrOYeS/p8s5bh3AYpMD9r3CIJtanHSCWnFCsPIw
+         /hesYDvbpVSiQTI1afBap2tw2ugq2aL2Sur2/9BhWE5So2HlVMlN5M6S8ccs6IK6Ldzh
+         +wxWJnq7dnvwbpMLcT3mASpdlEUPTaVTA7AazIssYrIDY9ucJA4vfYUemvvTtKn2tovO
+         lJjVDsOwv7/3P9XphLneTUXTI1ZD9soUX/qpt1m4n4BAme1tHfmbAL4cceRfMf7eFKhh
+         t3iRpkh/6ZHMGw0moeXPkTB+WTDhA7MgsmQA/X6tmPfjfMQsEo+OKRUBtFuuVDY5wzSf
+         eX7Q==
+X-Gm-Message-State: AJcUukcM8ZahlKLufK0H1V2XtT0GIN899FyU1V2PJM0+/GfK3XvzMW2n
+        o0kPoin07YrKIK/Zh71qAxI=
+X-Google-Smtp-Source: 
+ ALg8bN7upuyKWCD/cTB9FAkdcEyU6dlTStUcg49cEAv640NugO83fRipoQ9X2YGpIogSFxA7BbHmeQ==
+X-Received: by 2002:a1c:bbd6:: with SMTP id l205mr2979576wmf.97.1548344665032;
+        Thu, 24 Jan 2019 07:44:25 -0800 (PST)
+Received: from gmail.com (79.108.96.12.dyn.user.ono.com. [79.108.96.12])
+        by smtp.gmail.com with ESMTPSA id
+ k128sm80898610wmd.37.2019.01.24.07.44.23
+        (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
+        Thu, 24 Jan 2019 07:44:24 -0800 (PST)
+Date: Thu, 24 Jan 2019 16:44:20 +0100
+From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
+To: Krzysztof Kozlowski <krzk@kernel.org>
+Cc: Laura Abbott <labbott@redhat.com>,
+        Herbert Xu <herbert@gondor.apana.org.au>,
+        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
+        Catalin Marinas <catalin.marinas@arm.com>,
+        Martin Sebor <msebor@gcc.gnu.org>, linux-kernel@vger.kernel.org
+Subject: [PATCH] lib/crc32.c: mark crc32_le_base/__crc32c_le_base aliases as
+ __pure
+Message-ID: <20190124154420.GA11471@gmail.com>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+User-Agent: elm/2
+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.
+
+Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
+---
+I am picking this up through the compiler-attributes tree
+and putting it into -next along with the other cleanup
+for -Wmissing-attributes (unless some other maintainer wants it).
+
+ 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.