--- /dev/null
+From f34ee9cb2c5ac5af426fee6fa4591a34d187e696 Mon Sep 17 00:00:00 2001
+From: "Pratik R. Sampat" <psampat@linux.ibm.com>
+Date: Wed, 28 Jul 2021 17:35:00 +0530
+Subject: cpufreq: powernv: Fix init_chip_info initialization in numa=off
+
+From: Pratik R. Sampat <psampat@linux.ibm.com>
+
+commit f34ee9cb2c5ac5af426fee6fa4591a34d187e696 upstream.
+
+In the numa=off kernel command-line configuration init_chip_info() loops
+around the number of chips and attempts to copy the cpumask of that node
+which is NULL for all iterations after the first chip.
+
+Hence, store the cpu mask for each chip instead of derving cpumask from
+node while populating the "chips" struct array and copy that to the
+chips[i].mask
+
+Fixes: 053819e0bf84 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level")
+Cc: stable@vger.kernel.org # v4.3+
+Reported-by: Shirisha Ganta <shirisha.ganta1@ibm.com>
+Signed-off-by: Pratik R. Sampat <psampat@linux.ibm.com>
+Reviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
+[mpe: Rename goto label to out_free_chip_cpu_mask]
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210728120500.87549-2-psampat@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/cpufreq/powernv-cpufreq.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/drivers/cpufreq/powernv-cpufreq.c
++++ b/drivers/cpufreq/powernv-cpufreq.c
+@@ -36,6 +36,7 @@
+ #define MAX_PSTATE_SHIFT 32
+ #define LPSTATE_SHIFT 48
+ #define GPSTATE_SHIFT 56
++#define MAX_NR_CHIPS 32
+
+ #define MAX_RAMP_DOWN_TIME 5120
+ /*
+@@ -1046,12 +1047,20 @@ static int init_chip_info(void)
+ unsigned int *chip;
+ unsigned int cpu, i;
+ unsigned int prev_chip_id = UINT_MAX;
++ cpumask_t *chip_cpu_mask;
+ int ret = 0;
+
+ chip = kcalloc(num_possible_cpus(), sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
++ /* Allocate a chip cpu mask large enough to fit mask for all chips */
++ chip_cpu_mask = kcalloc(MAX_NR_CHIPS, sizeof(cpumask_t), GFP_KERNEL);
++ if (!chip_cpu_mask) {
++ ret = -ENOMEM;
++ goto free_and_return;
++ }
++
+ for_each_possible_cpu(cpu) {
+ unsigned int id = cpu_to_chip_id(cpu);
+
+@@ -1059,22 +1068,25 @@ static int init_chip_info(void)
+ prev_chip_id = id;
+ chip[nr_chips++] = id;
+ }
++ cpumask_set_cpu(cpu, &chip_cpu_mask[nr_chips-1]);
+ }
+
+ chips = kcalloc(nr_chips, sizeof(struct chip), GFP_KERNEL);
+ if (!chips) {
+ ret = -ENOMEM;
+- goto free_and_return;
++ goto out_free_chip_cpu_mask;
+ }
+
+ for (i = 0; i < nr_chips; i++) {
+ chips[i].id = chip[i];
+- cpumask_copy(&chips[i].mask, cpumask_of_node(chip[i]));
++ cpumask_copy(&chips[i].mask, &chip_cpu_mask[i]);
+ INIT_WORK(&chips[i].throttle, powernv_cpufreq_work_fn);
+ for_each_cpu(cpu, &chips[i].mask)
+ per_cpu(chip_info, cpu) = &chips[i];
+ }
+
++out_free_chip_cpu_mask:
++ kfree(chip_cpu_mask);
+ free_and_return:
+ kfree(chip);
+ return ret;
--- /dev/null
+From f87060d345232c7d855167a43faf006e24afa999 Mon Sep 17 00:00:00 2001
+From: Michael Wang <yun.wang@linux.alibaba.com>
+Date: Thu, 2 Sep 2021 14:58:40 -0700
+Subject: mm: fix panic caused by __page_handle_poison()
+
+From: Michael Wang <yun.wang@linux.alibaba.com>
+
+commit f87060d345232c7d855167a43faf006e24afa999 upstream.
+
+In commit 510d25c92ec4 ("mm/hwpoison: disable pcp for
+page_handle_poison()"), __page_handle_poison() was introduced, and if we
+mark:
+
+RET_A = dissolve_free_huge_page();
+RET_B = take_page_off_buddy();
+
+then __page_handle_poison was supposed to return TRUE When RET_A == 0 &&
+RET_B == TRUE
+
+But since it failed to take care the case when RET_A is -EBUSY or -ENOMEM,
+and just return the ret as a bool which actually become TRUE, it break the
+original logic.
+
+The following result is a huge page in freelist but was
+referenced as poisoned, and lead into the final panic:
+
+ kernel BUG at mm/internal.h:95!
+ invalid opcode: 0000 [#1] SMP PTI
+ skip...
+ RIP: 0010:set_page_refcounted mm/internal.h:95 [inline]
+ RIP: 0010:remove_hugetlb_page+0x23c/0x240 mm/hugetlb.c:1371
+ skip...
+ Call Trace:
+ remove_pool_huge_page+0xe4/0x110 mm/hugetlb.c:1892
+ return_unused_surplus_pages+0x8d/0x150 mm/hugetlb.c:2272
+ hugetlb_acct_memory.part.91+0x524/0x690 mm/hugetlb.c:4017
+
+This patch replaces 'bool' with 'int' to handle RET_A correctly.
+
+Link: https://lkml.kernel.org/r/61782ac6-1e8a-4f6f-35e6-e94fce3b37f5@linux.alibaba.com
+Fixes: 510d25c92ec4 ("mm/hwpoison: disable pcp for page_handle_poison()")
+Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com>
+Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Reported-by: Abaci <abaci@linux.alibaba.com>
+Cc: <stable@vger.kernel.org> [5.14+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory-failure.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/memory-failure.c
++++ b/mm/memory-failure.c
+@@ -68,7 +68,7 @@ atomic_long_t num_poisoned_pages __read_
+
+ static bool __page_handle_poison(struct page *page)
+ {
+- bool ret;
++ int ret;
+
+ zone_pcp_disable(page_zone(page));
+ ret = dissolve_free_huge_page(page);
+@@ -76,7 +76,7 @@ static bool __page_handle_poison(struct
+ ret = take_page_off_buddy(page);
+ zone_pcp_enable(page_zone(page));
+
+- return ret;
++ return ret > 0;
+ }
+
+ static bool page_handle_poison(struct page *page, bool hugepage_or_freepage, bool release)
--- /dev/null
+From 0792ec82175ec45a0f45af6e0f2d3cb49c527cd4 Mon Sep 17 00:00:00 2001
+From: Evgeny Novikov <novikov@ispras.ru>
+Date: Tue, 17 Aug 2021 12:29:30 +0300
+Subject: mtd: rawnand: intel: Fix error handling in probe
+
+From: Evgeny Novikov <novikov@ispras.ru>
+
+commit 0792ec82175ec45a0f45af6e0f2d3cb49c527cd4 upstream.
+
+ebu_nand_probe() did not invoke ebu_dma_cleanup() and
+clk_disable_unprepare() on some error handling paths. The patch fixes
+that.
+
+Found by Linux Driver Verification project (linuxtesting.org).
+
+Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC")
+Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
+Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
+Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
+Co-developed-by: Anton Vasilyev <vasilyev@ispras.ru>
+Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20210817092930.23040-1-novikov@ispras.ru
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/intel-nand-controller.c | 27 ++++++++++++++++++---------
+ 1 file changed, 18 insertions(+), 9 deletions(-)
+
+--- a/drivers/mtd/nand/raw/intel-nand-controller.c
++++ b/drivers/mtd/nand/raw/intel-nand-controller.c
+@@ -631,19 +631,26 @@ static int ebu_nand_probe(struct platfor
+ ebu_host->clk_rate = clk_get_rate(ebu_host->clk);
+
+ ebu_host->dma_tx = dma_request_chan(dev, "tx");
+- if (IS_ERR(ebu_host->dma_tx))
+- return dev_err_probe(dev, PTR_ERR(ebu_host->dma_tx),
+- "failed to request DMA tx chan!.\n");
++ if (IS_ERR(ebu_host->dma_tx)) {
++ ret = dev_err_probe(dev, PTR_ERR(ebu_host->dma_tx),
++ "failed to request DMA tx chan!.\n");
++ goto err_disable_unprepare_clk;
++ }
+
+ ebu_host->dma_rx = dma_request_chan(dev, "rx");
+- if (IS_ERR(ebu_host->dma_rx))
+- return dev_err_probe(dev, PTR_ERR(ebu_host->dma_rx),
+- "failed to request DMA rx chan!.\n");
++ if (IS_ERR(ebu_host->dma_rx)) {
++ ret = dev_err_probe(dev, PTR_ERR(ebu_host->dma_rx),
++ "failed to request DMA rx chan!.\n");
++ ebu_host->dma_rx = NULL;
++ goto err_cleanup_dma;
++ }
+
+ resname = devm_kasprintf(dev, GFP_KERNEL, "addr_sel%d", cs);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, resname);
+- if (!res)
+- return -EINVAL;
++ if (!res) {
++ ret = -EINVAL;
++ goto err_cleanup_dma;
++ }
+ ebu_host->cs[cs].addr_sel = res->start;
+ writel(ebu_host->cs[cs].addr_sel | EBU_ADDR_MASK(5) | EBU_ADDR_SEL_REGEN,
+ ebu_host->ebu + EBU_ADDR_SEL(cs));
+@@ -653,7 +660,8 @@ static int ebu_nand_probe(struct platfor
+ mtd = nand_to_mtd(&ebu_host->chip);
+ if (!mtd->name) {
+ dev_err(ebu_host->dev, "NAND label property is mandatory\n");
+- return -EINVAL;
++ ret = -EINVAL;
++ goto err_cleanup_dma;
+ }
+
+ mtd->dev.parent = dev;
+@@ -681,6 +689,7 @@ err_clean_nand:
+ nand_cleanup(&ebu_host->chip);
+ err_cleanup_dma:
+ ebu_dma_cleanup(ebu_host);
++err_disable_unprepare_clk:
+ clk_disable_unprepare(ebu_host->clk);
+
+ return ret;
--- /dev/null
+From 52d5a0c6bd8a89f460243ed937856354f8f253a3 Mon Sep 17 00:00:00 2001
+From: chenying <chenying.kernel@bytedance.com>
+Date: Mon, 16 Aug 2021 18:02:56 +0800
+Subject: ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup()
+
+From: chenying <chenying.kernel@bytedance.com>
+
+commit 52d5a0c6bd8a89f460243ed937856354f8f253a3 upstream.
+
+If function ovl_instantiate() returns an error, ovl_cleanup will be called
+and try to remove newdentry from wdir, but the newdentry has been moved to
+udir at this time. This will causes BUG_ON(victim->d_parent->d_inode !=
+dir) in fs/namei.c:may_delete.
+
+Signed-off-by: chenying <chenying.kernel@bytedance.com>
+Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created inode")
+Link: https://lore.kernel.org/linux-unionfs/e6496a94-a161-dc04-c38a-d2544633acb4@bytedance.com/
+Cc: <stable@vger.kernel.org> # v4.18
+Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/overlayfs/dir.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/overlayfs/dir.c
++++ b/fs/overlayfs/dir.c
+@@ -542,8 +542,10 @@ static int ovl_create_over_whiteout(stru
+ goto out_cleanup;
+ }
+ err = ovl_instantiate(dentry, inode, newdentry, hardlink);
+- if (err)
+- goto out_cleanup;
++ if (err) {
++ ovl_cleanup(udir, newdentry);
++ dput(newdentry);
++ }
+ out_dput:
+ dput(upper);
+ out_unlock:
--- /dev/null
+From 5f6e0fe01b6b33894cf6f61b359ab5a6d2b7674e Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <masahiroy@kernel.org>
+Date: Thu, 10 Jun 2021 11:03:31 +0900
+Subject: parisc: Fix compile failure when building 64-bit kernel natively
+
+From: Masahiro Yamada <masahiroy@kernel.org>
+
+commit 5f6e0fe01b6b33894cf6f61b359ab5a6d2b7674e upstream.
+
+Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is
+a cross build or not") broke 64-bit parisc builds on 32-bit parisc
+systems.
+
+Helge mentioned:
+ - 64-bit parisc userspace is not supported yet [1]
+ - hppa gcc does not support "-m64" flag [2]
+
+That means, parisc developers working on a 32-bit parisc machine need
+to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit
+parisc kernel.
+
+After the offending commit, gcc is used in such a case because
+both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is
+unset.
+
+A correct way is to introduce ARCH=parisc64 because building the 64-bit
+parisc kernel on a 32-bit parisc system is not exactly a native build,
+but rather a semi-cross build.
+
+[1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t
+[2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/
+
+Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not")
+Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
+Reported-by: Meelis Roos <mroos@linux.ee>
+Tested-by: Meelis Roos <mroos@linux.ee>
+Cc: <stable@vger.kernel.org> # v5.13+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Makefile | 5 +++++
+ arch/parisc/Makefile | 6 +++---
+ scripts/subarch.include | 2 +-
+ 3 files changed, 9 insertions(+), 4 deletions(-)
+
+--- a/Makefile
++++ b/Makefile
+@@ -404,6 +404,11 @@ ifeq ($(ARCH),sparc64)
+ SRCARCH := sparc
+ endif
+
++# Additional ARCH settings for parisc
++ifeq ($(ARCH),parisc64)
++ SRCARCH := parisc
++endif
++
+ export cross_compiling :=
+ ifneq ($(SRCARCH),$(SUBARCH))
+ cross_compiling := 1
+--- a/arch/parisc/Makefile
++++ b/arch/parisc/Makefile
+@@ -25,18 +25,18 @@ CHECKFLAGS += -D__hppa__=1
+ ifdef CONFIG_64BIT
+ UTS_MACHINE := parisc64
+ CHECKFLAGS += -D__LP64__=1
+-CC_ARCHES = hppa64
+ LD_BFD := elf64-hppa-linux
+ else # 32-bit
+-CC_ARCHES = hppa hppa2.0 hppa1.1
+ LD_BFD := elf32-hppa-linux
+ endif
+
+ # select defconfig based on actual architecture
+-ifeq ($(shell uname -m),parisc64)
++ifeq ($(ARCH),parisc64)
+ KBUILD_DEFCONFIG := generic-64bit_defconfig
++ CC_ARCHES := hppa64
+ else
+ KBUILD_DEFCONFIG := generic-32bit_defconfig
++ CC_ARCHES := hppa hppa2.0 hppa1.1
+ endif
+
+ export LD_BFD
+--- a/scripts/subarch.include
++++ b/scripts/subarch.include
+@@ -7,7 +7,7 @@
+ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+- -e s/s390x/s390/ -e s/parisc64/parisc/ \
++ -e s/s390x/s390/ \
+ -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
+ -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
+ -e s/riscv.*/riscv/)
--- /dev/null
+From 030f653078316a9cc9ca6bd1b0234dcf858be35d Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 30 Aug 2021 05:42:27 -0400
+Subject: parisc: fix crash with signals and alloca
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream.
+
+I was debugging some crashes on parisc and I found out that there is a
+crash possibility if a function using alloca is interrupted by a signal.
+The reason for the crash is that the gcc alloca implementation leaves
+garbage in the upper 32 bits of the sp register. This normally doesn't
+matter (the upper bits are ignored because the PSW W-bit is clear),
+however the signal delivery routine in the kernel uses full 64 bits of sp
+and it fails with -EFAULT if the upper 32 bits are not zero.
+
+I created this program that demonstrates the problem:
+
+#include <stdlib.h>
+#include <unistd.h>
+#include <signal.h>
+#include <alloca.h>
+
+static __attribute__((noinline,noclone)) void aa(int *size)
+{
+ void * volatile p = alloca(-*size);
+ while (1) ;
+}
+
+static void handler(int sig)
+{
+ write(1, "signal delivered\n", 17);
+ _exit(0);
+}
+
+int main(void)
+{
+ int size = -0x100;
+ signal(SIGALRM, handler);
+ alarm(1);
+ aa(&size);
+}
+
+If you compile it with optimizations, it will crash.
+The "aa" function has this disassembly:
+
+000106a0 <aa>:
+ 106a0: 08 03 02 41 copy r3,r1
+ 106a4: 08 1e 02 43 copy sp,r3
+ 106a8: 6f c1 00 80 stw,ma r1,40(sp)
+ 106ac: 37 dc 3f c1 ldo -20(sp),ret0
+ 106b0: 0c 7c 12 90 stw ret0,8(r3)
+ 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00
+ 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F
+ 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100
+ 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx
+ 106c4: e8 1f 1f f7 b,l,n 106c4 <aa+0x24>,r0
+
+This patch fixes the bug by truncating the "usp" variable to 32 bits.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/signal.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/parisc/kernel/signal.c
++++ b/arch/parisc/kernel/signal.c
+@@ -237,6 +237,12 @@ setup_rt_frame(struct ksignal *ksig, sig
+ #endif
+
+ usp = (regs->gr[30] & ~(0x01UL));
++#ifdef CONFIG_64BIT
++ if (is_compat_task()) {
++ /* The gcc alloca implementation leaves garbage in the upper 32 bits of sp */
++ usp = (compat_uint_t)usp;
++ }
++#endif
+ /*FIXME: frame_size parameter is unused, remove it. */
+ frame = get_sigframe(&ksig->ka, usp, sizeof(*frame));
+
--- /dev/null
+From 11e4b63abbe23872b45f325a7c6c8b7f9ff42cad Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.com>
+Date: Fri, 2 Jul 2021 17:06:57 +0200
+Subject: printk/console: Check consistent sequence number when handling race in console_unlock()
+
+From: Petr Mladek <pmladek@suse.com>
+
+commit 11e4b63abbe23872b45f325a7c6c8b7f9ff42cad upstream.
+
+The standard printk() tries to flush the message to the console
+immediately. It tries to take the console lock. If the lock is
+already taken then the current owner is responsible for flushing
+even the new message.
+
+There is a small race window between checking whether a new message is
+available and releasing the console lock. It is solved by re-checking
+the state after releasing the console lock. If the check is positive
+then console_unlock() tries to take the lock again and process the new
+message as well.
+
+The commit 996e966640ddea7b535c ("printk: remove logbuf_lock") causes that
+console_seq is not longer read atomically. As a result, the re-check might
+be done with an inconsistent 64-bit index.
+
+Solve it by using the last sequence number that has been checked under
+the console lock. In the worst case, it will take the lock again only
+to realized that the new message has already been proceed. But it
+was possible even before.
+
+The variable next_seq is marked as __maybe_unused to call down compiler
+warning when CONFIG_PRINTK is not defined.
+
+Fixes: commit 996e966640ddea7b535c ("printk: remove logbuf_lock")
+Reported-by: kernel test robot <lkp@intel.com> # unused next_seq warning
+Cc: stable@vger.kernel.org # 5.13
+Signed-off-by: Petr Mladek <pmladek@suse.com>
+Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Reviewed-by: John Ogness <john.ogness@linutronix.de>
+Link: https://lore.kernel.org/r/20210702150657.26760-1-pmladek@suse.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/printk/printk.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/kernel/printk/printk.c
++++ b/kernel/printk/printk.c
+@@ -2545,6 +2545,7 @@ void console_unlock(void)
+ bool do_cond_resched, retry;
+ struct printk_info info;
+ struct printk_record r;
++ u64 __maybe_unused next_seq;
+
+ if (console_suspended) {
+ up_console_sem();
+@@ -2654,8 +2655,10 @@ skip:
+ cond_resched();
+ }
+
+- console_locked = 0;
++ /* Get consistent value of the next-to-be-used sequence number. */
++ next_seq = console_seq;
+
++ console_locked = 0;
+ up_console_sem();
+
+ /*
+@@ -2664,7 +2667,7 @@ skip:
+ * there's a new owner and the console_unlock() from them will do the
+ * flush, no worries.
+ */
+- retry = prb_read_valid(prb, console_seq, NULL);
++ retry = prb_read_valid(prb, next_seq, NULL);
+ printk_safe_exit_irqrestore(flags);
+
+ if (retry && console_trylock())
--- /dev/null
+From 93ebb6828723b8aef114415c4dc3518342f7dcad Mon Sep 17 00:00:00 2001
+From: Halil Pasic <pasic@linux.ibm.com>
+Date: Sat, 24 Jul 2021 01:17:46 +0200
+Subject: s390/pv: fix the forcing of the swiotlb
+
+From: Halil Pasic <pasic@linux.ibm.com>
+
+commit 93ebb6828723b8aef114415c4dc3518342f7dcad upstream.
+
+Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for
+swiotlb data bouncing") if code sets swiotlb_force it needs to do so
+before the swiotlb is initialised. Otherwise
+io_tlb_default_mem->force_bounce will not get set to true, and devices
+that use (the default) swiotlb will not bounce despite switolb_force
+having the value of SWIOTLB_FORCE.
+
+Let us restore swiotlb functionality for PV by fulfilling this new
+requirement.
+
+This change addresses what turned out to be a fragility in
+commit 64e1f0c531d1 ("s390/mm: force swiotlb for protected
+virtualization"), which ain't exactly broken in its original context,
+but could give us some more headache if people backport the broken
+change and forget this fix.
+
+Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
+Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
+Fixes: 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing")
+Fixes: 64e1f0c531d1 ("s390/mm: force swiotlb for protected virtualization")
+Cc: stable@vger.kernel.org #5.3+
+Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/mm/init.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/mm/init.c
++++ b/arch/s390/mm/init.c
+@@ -186,9 +186,9 @@ static void pv_init(void)
+ return;
+
+ /* make sure bounce buffers are shared */
++ swiotlb_force = SWIOTLB_FORCE;
+ swiotlb_init(1);
+ swiotlb_update_mem_attributes();
+- swiotlb_force = SWIOTLB_FORCE;
+ }
+
+ void __init mem_init(void)
--- /dev/null
+From a052096bdd6809eeab809202726634d1ac975aa1 Mon Sep 17 00:00:00 2001
+From: Sven Schnelle <svens@linux.ibm.com>
+Date: Fri, 27 Aug 2021 20:21:05 +0200
+Subject: s390/topology: fix topology information when calling cpu hotplug notifiers
+
+From: Sven Schnelle <svens@linux.ibm.com>
+
+commit a052096bdd6809eeab809202726634d1ac975aa1 upstream.
+
+The cpu hotplug notifiers are called without updating the core/thread
+masks when a new CPU is added. This causes problems with code setting
+up data structures in a cpu hotplug notifier, and relying on that later
+in normal code.
+
+This caused a crash in the new core scheduling code (SCHED_CORE),
+where rq->core was set up in a notifier depending on cpu masks.
+
+To fix this, add a cpu_setup_mask which is used in update_cpu_masks()
+instead of the cpu_online_mask to determine whether the cpu masks should
+be set for a certain cpu. Also move update_cpu_masks() to update the
+masks before calling notify_cpu_starting() so that the notifiers are
+seeing the updated masks.
+
+Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
+Cc: <stable@vger.kernel.org>
+[hca@linux.ibm.com: get rid of cpu_online_mask handling]
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/include/asm/smp.h | 1 +
+ arch/s390/kernel/smp.c | 9 +++++++--
+ arch/s390/kernel/topology.c | 13 +++++++------
+ 3 files changed, 15 insertions(+), 8 deletions(-)
+
+--- a/arch/s390/include/asm/smp.h
++++ b/arch/s390/include/asm/smp.h
+@@ -18,6 +18,7 @@ extern struct mutex smp_cpu_state_mutex;
+ extern unsigned int smp_cpu_mt_shift;
+ extern unsigned int smp_cpu_mtid;
+ extern __vector128 __initdata boot_cpu_vector_save_area[__NUM_VXRS];
++extern cpumask_t cpu_setup_mask;
+
+ extern int __cpu_up(unsigned int cpu, struct task_struct *tidle);
+
+--- a/arch/s390/kernel/smp.c
++++ b/arch/s390/kernel/smp.c
+@@ -95,6 +95,7 @@ __vector128 __initdata boot_cpu_vector_s
+ #endif
+
+ static unsigned int smp_max_threads __initdata = -1U;
++cpumask_t cpu_setup_mask;
+
+ static int __init early_nosmt(char *s)
+ {
+@@ -894,13 +895,14 @@ static void smp_init_secondary(void)
+ vtime_init();
+ vdso_getcpu_init();
+ pfault_init();
++ cpumask_set_cpu(cpu, &cpu_setup_mask);
++ update_cpu_masks();
+ notify_cpu_starting(cpu);
+ if (topology_cpu_dedicated(cpu))
+ set_cpu_flag(CIF_DEDICATED_CPU);
+ else
+ clear_cpu_flag(CIF_DEDICATED_CPU);
+ set_cpu_online(cpu, true);
+- update_cpu_masks();
+ inc_irq_stat(CPU_RST);
+ local_irq_enable();
+ cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
+@@ -955,10 +957,13 @@ early_param("possible_cpus", _setup_poss
+ int __cpu_disable(void)
+ {
+ unsigned long cregs[16];
++ int cpu;
+
+ /* Handle possible pending IPIs */
+ smp_handle_ext_call();
+- set_cpu_online(smp_processor_id(), false);
++ cpu = smp_processor_id();
++ set_cpu_online(cpu, false);
++ cpumask_clear_cpu(cpu, &cpu_setup_mask);
+ update_cpu_masks();
+ /* Disable pseudo page faults on this cpu. */
+ pfault_fini();
+--- a/arch/s390/kernel/topology.c
++++ b/arch/s390/kernel/topology.c
+@@ -67,7 +67,7 @@ static void cpu_group_map(cpumask_t *dst
+ static cpumask_t mask;
+
+ cpumask_clear(&mask);
+- if (!cpu_online(cpu))
++ if (!cpumask_test_cpu(cpu, &cpu_setup_mask))
+ goto out;
+ cpumask_set_cpu(cpu, &mask);
+ switch (topology_mode) {
+@@ -88,7 +88,7 @@ static void cpu_group_map(cpumask_t *dst
+ case TOPOLOGY_MODE_SINGLE:
+ break;
+ }
+- cpumask_and(&mask, &mask, cpu_online_mask);
++ cpumask_and(&mask, &mask, &cpu_setup_mask);
+ out:
+ cpumask_copy(dst, &mask);
+ }
+@@ -99,16 +99,16 @@ static void cpu_thread_map(cpumask_t *ds
+ int i;
+
+ cpumask_clear(&mask);
+- if (!cpu_online(cpu))
++ if (!cpumask_test_cpu(cpu, &cpu_setup_mask))
+ goto out;
+ cpumask_set_cpu(cpu, &mask);
+ if (topology_mode != TOPOLOGY_MODE_HW)
+ goto out;
+ cpu -= cpu % (smp_cpu_mtid + 1);
+- for (i = 0; i <= smp_cpu_mtid; i++)
+- if (cpu_present(cpu + i))
++ for (i = 0; i <= smp_cpu_mtid; i++) {
++ if (cpumask_test_cpu(cpu + i, &cpu_setup_mask))
+ cpumask_set_cpu(cpu + i, &mask);
+- cpumask_and(&mask, &mask, cpu_online_mask);
++ }
+ out:
+ cpumask_copy(dst, &mask);
+ }
+@@ -569,6 +569,7 @@ void __init topology_init_early(void)
+ alloc_masks(info, &book_info, 2);
+ alloc_masks(info, &drawer_info, 3);
+ out:
++ cpumask_set_cpu(0, &cpu_setup_mask);
+ __arch_update_cpu_topology();
+ __arch_update_dedicated_flag(NULL);
+ }
--- /dev/null
+From 44d01fc86d952f5a8b8b32bdb4841504d5833d95 Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Tue, 20 Apr 2021 20:01:47 +0200
+Subject: scsi: BusLogic: Fix missing pr_cont() use
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream.
+
+Update BusLogic driver's messaging system to use pr_cont() for continuation
+lines, bringing messy output:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0: PCI Bus: 0, Device: 19, Address:
+0xE0012000,
+Host Adapter SCSI ID: 7
+scsi0: Parity Checking: Enabled, Extended Translation: Enabled
+scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0: Tagged Queue Depth:
+Automatic
+, Untagged Queue Depth: 3
+scsi0: SCSI Bus Termination: Both Enabled
+, SCAM: Disabled
+
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+back to order:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level
+scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7
+scsi0: Parity Checking: Enabled, Extended Translation: Enabled
+scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled
+scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled
+scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211
+scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192
+scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3
+scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled
+scsi0: *** BusLogic BT-958 Initialized Successfully ***
+scsi host0: BusLogic BT-958
+
+Also diagnostic output such as with the BusLogic=TraceConfiguration
+parameter is affected and becomes vertical and therefore hard to read.
+This has now been corrected, e.g.:
+
+pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17
+blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00
+blogic_cmd(95) Status = 28: (Modify I/O Address)
+blogic_cmd(91) Status = 30: 1 ==> 1: 01
+blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 *****
+scsi: Copyright 1995-1998 by Leonard N. Zubkoff <lnz@dandelion.com>
+blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30
+blogic_cmd(0B) Status = 30: 3 ==> 3: 00 08 07
+blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00
+blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D
+blogic_cmd(84) Status = 30: 1 ==> 1: 37
+blogic_cmd(8B) Status = 30: 5 ==> 5: 39 35 38 20 20
+blogic_cmd(85) Status = 30: 1 ==> 1: 42
+blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00
+blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC
+scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter
+
+etc.
+
+Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk
+Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines")
+Cc: stable@vger.kernel.org # v4.9+
+Acked-by: Khalid Aziz <khalid@gonehiking.org>
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/BusLogic.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/BusLogic.c
++++ b/drivers/scsi/BusLogic.c
+@@ -3451,7 +3451,7 @@ static void blogic_msg(enum blogic_msgle
+ if (buf[0] != '\n' || len > 1)
+ printk("%sscsi%d: %s", blogic_msglevelmap[msglevel], adapter->host_no, buf);
+ } else
+- printk("%s", buf);
++ pr_cont("%s", buf);
+ } else {
+ if (begin) {
+ if (adapter != NULL && adapter->adapter_initd)
+@@ -3459,7 +3459,7 @@ static void blogic_msg(enum blogic_msgle
+ else
+ printk("%s%s", blogic_msglevelmap[msglevel], buf);
+ } else
+- printk("%s", buf);
++ pr_cont("%s", buf);
+ }
+ begin = (buf[len - 1] == '\n');
+ }
--- /dev/null
+From 62e0dec59c1e139dab55aff5aa442adc97804271 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <skashyap@marvell.com>
+Date: Mon, 9 Aug 2021 21:37:17 -0700
+Subject: scsi: qla2xxx: Changes to support kdump kernel
+
+From: Saurav Kashyap <skashyap@marvell.com>
+
+commit 62e0dec59c1e139dab55aff5aa442adc97804271 upstream.
+
+Avoid allocating firmware dump and only allocate a single queue for a kexec
+kernel.
+
+Link: https://lore.kernel.org/r/20210810043720.1137-12-njavali@marvell.com
+Cc: stable@vger.kernel.org
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_os.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/scsi/qla2xxx/qla_os.c
++++ b/drivers/scsi/qla2xxx/qla_os.c
+@@ -14,6 +14,7 @@
+ #include <linux/slab.h>
+ #include <linux/blk-mq-pci.h>
+ #include <linux/refcount.h>
++#include <linux/crash_dump.h>
+
+ #include <scsi/scsi_tcq.h>
+ #include <scsi/scsicam.h>
+@@ -2818,6 +2819,11 @@ qla2x00_probe_one(struct pci_dev *pdev,
+ return ret;
+ }
+
++ if (is_kdump_kernel()) {
++ ql2xmqsupport = 0;
++ ql2xallocfwdump = 0;
++ }
++
+ /* This may fail but that's ok */
+ pci_enable_pcie_error_reporting(pdev);
+
--- /dev/null
+From c8fadf019964d0eb1da410ba8b629494d3339db9 Mon Sep 17 00:00:00 2001
+From: Saurav Kashyap <skashyap@marvell.com>
+Date: Mon, 9 Aug 2021 21:37:19 -0700
+Subject: scsi: qla2xxx: Sync queue idx with queue_pair_map idx
+
+From: Saurav Kashyap <skashyap@marvell.com>
+
+commit c8fadf019964d0eb1da410ba8b629494d3339db9 upstream.
+
+The first invocation of function find_first_zero_bit will return 0 and
+queue_id gets set to 0.
+
+An index of queue_pair_map also gets set to 0.
+
+ qpair_id = find_first_zero_bit(ha->qpair_qid_map, ha->max_qpairs);
+
+ set_bit(qpair_id, ha->qpair_qid_map);
+ ha->queue_pair_map[qpair_id] = qpair;
+
+In the alloc_queue callback driver checks the map, if queue is already
+allocated:
+
+ ha->queue_pair_map[qidx]
+
+This works fine as long as max_qpairs is greater than nvme_max_hw_queues(8)
+since the size of the queue_pair_map is equal to max_qpair. In case nr_cpus
+is less than 8, max_qpairs is less than 8. This creates wrong value
+returned as qpair.
+
+[ 1572.353669] qla2xxx [0000:24:00.3]-2121:6: Returning existing qpair of 4e00000000000000 for idx=2
+[ 1572.354458] general protection fault: 0000 [#1] SMP PTI
+[ 1572.354461] CPU: 1 PID: 44 Comm: kworker/1:1H Kdump: loaded Tainted: G IOE --------- - - 4.18.0-304.el8.x86_64 #1
+[ 1572.354462] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 03/01/2013
+[ 1572.354467] Workqueue: kblockd blk_mq_run_work_fn
+[ 1572.354485] RIP: 0010:qla_nvme_post_cmd+0x92/0x760 [qla2xxx]
+[ 1572.354486] Code: 84 24 5c 01 00 00 00 00 b8 0a 74 1e 66 83 79 48 00 0f 85 a8 03 00 00 48 8b 44 24 08 48 89 ee 4c 89 e7 8b 50 24 e8 5e 8e 00 00 <f0> 41 ff 47 04 0f ae f0 41 f6 47 24 04 74 19 f0 41 ff 4f 04 b8 f0
+[ 1572.354487] RSP: 0018:ffff9c81c645fc90 EFLAGS: 00010246
+[ 1572.354489] RAX: 0000000000000001 RBX: ffff8ea3e5070138 RCX: 0000000000000001
+[ 1572.354490] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8ea4c866b800
+[ 1572.354491] RBP: ffff8ea4c866b800 R08: 0000000000005010 R09: ffff8ea4c866b800
+[ 1572.354492] R10: 0000000000000001 R11: 000000069d1ca3ff R12: ffff8ea4bc460000
+[ 1572.354493] R13: ffff8ea3e50702b0 R14: ffff8ea4c4c16a58 R15: 4e00000000000000
+[ 1572.354494] FS: 0000000000000000(0000) GS:ffff8ea4dfd00000(0000) knlGS:0000000000000000
+[ 1572.354495] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 1572.354496] CR2: 000055884504fa58 CR3: 00000005a1410001 CR4: 00000000000606e0
+[ 1572.354497] Call Trace:
+[ 1572.354503] ? check_preempt_curr+0x62/0x90
+[ 1572.354506] ? dma_direct_map_sg+0x72/0x1f0
+[ 1572.354509] ? nvme_fc_start_fcp_op.part.32+0x175/0x460 [nvme_fc]
+[ 1572.354511] ? blk_mq_dispatch_rq_list+0x11c/0x730
+[ 1572.354515] ? __switch_to_asm+0x35/0x70
+[ 1572.354516] ? __switch_to_asm+0x41/0x70
+[ 1572.354518] ? __switch_to_asm+0x35/0x70
+[ 1572.354519] ? __switch_to_asm+0x41/0x70
+[ 1572.354521] ? __switch_to_asm+0x35/0x70
+[ 1572.354522] ? __switch_to_asm+0x41/0x70
+[ 1572.354523] ? __switch_to_asm+0x35/0x70
+[ 1572.354525] ? entry_SYSCALL_64_after_hwframe+0xb9/0xca
+[ 1572.354527] ? __switch_to_asm+0x41/0x70
+[ 1572.354529] ? __blk_mq_sched_dispatch_requests+0xc6/0x170
+[ 1572.354531] ? blk_mq_sched_dispatch_requests+0x30/0x60
+[ 1572.354532] ? __blk_mq_run_hw_queue+0x51/0xd0
+[ 1572.354535] ? process_one_work+0x1a7/0x360
+[ 1572.354537] ? create_worker+0x1a0/0x1a0
+[ 1572.354538] ? worker_thread+0x30/0x390
+[ 1572.354540] ? create_worker+0x1a0/0x1a0
+[ 1572.354541] ? kthread+0x116/0x130
+[ 1572.354543] ? kthread_flush_work_fn+0x10/0x10
+[ 1572.354545] ? ret_from_fork+0x35/0x40
+
+Fix is to use index 0 for admin and first IO queue.
+
+Link: https://lore.kernel.org/r/20210810043720.1137-14-njavali@marvell.com
+Fixes: e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport registration")
+Cc: stable@vger.kernel.org
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Saurav Kashyap <skashyap@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_nvme.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_nvme.c
++++ b/drivers/scsi/qla2xxx/qla_nvme.c
+@@ -91,8 +91,9 @@ static int qla_nvme_alloc_queue(struct n
+ struct qla_hw_data *ha;
+ struct qla_qpair *qpair;
+
+- if (!qidx)
+- qidx++;
++ /* Map admin queue and 1st IO queue to index 0 */
++ if (qidx)
++ qidx--;
+
+ vha = (struct scsi_qla_host *)lport->private;
+ ha = vha->hw;
fix-array-index-out-of-bounds-in-taprio_change.patch
net-w5100-check-return-value-after-calling-platform_.patch
net-hns3-clean-up-a-type-mismatch-warning.patch
+parisc-fix-crash-with-signals-and-alloca.patch
+parisc-fix-compile-failure-when-building-64-bit-kernel-natively.patch
+printk-console-check-consistent-sequence-number-when-handling-race-in-console_unlock.patch
+ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch
+scsi-buslogic-fix-missing-pr_cont-use.patch
+scsi-qla2xxx-changes-to-support-kdump-kernel.patch
+scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch
+mtd-rawnand-intel-fix-error-handling-in-probe.patch
+cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch
+s390-pv-fix-the-forcing-of-the-swiotlb.patch
+s390-topology-fix-topology-information-when-calling-cpu-hotplug-notifiers.patch
+mm-fix-panic-caused-by-__page_handle_poison.patch