From: Greg Kroah-Hartman Date: Thu, 16 Sep 2021 12:16:45 +0000 (+0200) Subject: 5.14-stable patches X-Git-Tag: v5.10.67~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b07d6f432e9570f98f96b9da271b3d55cfb9312b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.14-stable patches added patches: cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch mm-fix-panic-caused-by-__page_handle_poison.patch mtd-rawnand-intel-fix-error-handling-in-probe.patch ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch parisc-fix-compile-failure-when-building-64-bit-kernel-natively.patch parisc-fix-crash-with-signals-and-alloca.patch printk-console-check-consistent-sequence-number-when-handling-race-in-console_unlock.patch s390-pv-fix-the-forcing-of-the-swiotlb.patch s390-topology-fix-topology-information-when-calling-cpu-hotplug-notifiers.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 --- diff --git a/queue-5.14/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch b/queue-5.14/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch new file mode 100644 index 00000000000..de8cc0676db --- /dev/null +++ b/queue-5.14/cpufreq-powernv-fix-init_chip_info-initialization-in-numa-off.patch @@ -0,0 +1,89 @@ +From f34ee9cb2c5ac5af426fee6fa4591a34d187e696 Mon Sep 17 00:00:00 2001 +From: "Pratik R. Sampat" +Date: Wed, 28 Jul 2021 17:35:00 +0530 +Subject: cpufreq: powernv: Fix init_chip_info initialization in numa=off + +From: Pratik R. Sampat + +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 +Signed-off-by: Pratik R. Sampat +Reviewed-by: Gautham R. Shenoy +[mpe: Rename goto label to out_free_chip_cpu_mask] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20210728120500.87549-2-psampat@linux.ibm.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.14/mm-fix-panic-caused-by-__page_handle_poison.patch b/queue-5.14/mm-fix-panic-caused-by-__page_handle_poison.patch new file mode 100644 index 00000000000..8c76441ff12 --- /dev/null +++ b/queue-5.14/mm-fix-panic-caused-by-__page_handle_poison.patch @@ -0,0 +1,72 @@ +From f87060d345232c7d855167a43faf006e24afa999 Mon Sep 17 00:00:00 2001 +From: Michael Wang +Date: Thu, 2 Sep 2021 14:58:40 -0700 +Subject: mm: fix panic caused by __page_handle_poison() + +From: Michael Wang + +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 +Acked-by: Naoya Horiguchi +Reported-by: Abaci +Cc: [5.14+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.14/mtd-rawnand-intel-fix-error-handling-in-probe.patch b/queue-5.14/mtd-rawnand-intel-fix-error-handling-in-probe.patch new file mode 100644 index 00000000000..f119b3a724e --- /dev/null +++ b/queue-5.14/mtd-rawnand-intel-fix-error-handling-in-probe.patch @@ -0,0 +1,84 @@ +From 0792ec82175ec45a0f45af6e0f2d3cb49c527cd4 Mon Sep 17 00:00:00 2001 +From: Evgeny Novikov +Date: Tue, 17 Aug 2021 12:29:30 +0300 +Subject: mtd: rawnand: intel: Fix error handling in probe + +From: Evgeny Novikov + +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 +Co-developed-by: Kirill Shilimanov +Signed-off-by: Kirill Shilimanov +Co-developed-by: Anton Vasilyev +Signed-off-by: Anton Vasilyev +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20210817092930.23040-1-novikov@ispras.ru +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.14/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch b/queue-5.14/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch new file mode 100644 index 00000000000..8c7cd03b468 --- /dev/null +++ b/queue-5.14/ovl-fix-bug_on-in-may_delete-when-called-from-ovl_cleanup.patch @@ -0,0 +1,39 @@ +From 52d5a0c6bd8a89f460243ed937856354f8f253a3 Mon Sep 17 00:00:00 2001 +From: chenying +Date: Mon, 16 Aug 2021 18:02:56 +0800 +Subject: ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup() + +From: chenying + +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 +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: # v4.18 +Signed-off-by: Miklos Szeredi +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-5.14/parisc-fix-compile-failure-when-building-64-bit-kernel-natively.patch b/queue-5.14/parisc-fix-compile-failure-when-building-64-bit-kernel-natively.patch new file mode 100644 index 00000000000..32244bf0fae --- /dev/null +++ b/queue-5.14/parisc-fix-compile-failure-when-building-64-bit-kernel-natively.patch @@ -0,0 +1,94 @@ +From 5f6e0fe01b6b33894cf6f61b359ab5a6d2b7674e Mon Sep 17 00:00:00 2001 +From: Masahiro Yamada +Date: Thu, 10 Jun 2021 11:03:31 +0900 +Subject: parisc: Fix compile failure when building 64-bit kernel natively + +From: Masahiro Yamada + +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 +Reported-by: Meelis Roos +Tested-by: Meelis Roos +Cc: # v5.13+ +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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/) diff --git a/queue-5.14/parisc-fix-crash-with-signals-and-alloca.patch b/queue-5.14/parisc-fix-crash-with-signals-and-alloca.patch new file mode 100644 index 00000000000..068ae253a0e --- /dev/null +++ b/queue-5.14/parisc-fix-crash-with-signals-and-alloca.patch @@ -0,0 +1,84 @@ +From 030f653078316a9cc9ca6bd1b0234dcf858be35d Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Mon, 30 Aug 2021 05:42:27 -0400 +Subject: parisc: fix crash with signals and alloca + +From: Mikulas Patocka + +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 +#include +#include +#include + +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 : + 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 ,r0 + +This patch fixes the bug by truncating the "usp" variable to 32 bits. + +Signed-off-by: Mikulas Patocka +Cc: stable@vger.kernel.org +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + 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)); + diff --git a/queue-5.14/printk-console-check-consistent-sequence-number-when-handling-race-in-console_unlock.patch b/queue-5.14/printk-console-check-consistent-sequence-number-when-handling-race-in-console_unlock.patch new file mode 100644 index 00000000000..847f047ea7c --- /dev/null +++ b/queue-5.14/printk-console-check-consistent-sequence-number-when-handling-race-in-console_unlock.patch @@ -0,0 +1,75 @@ +From 11e4b63abbe23872b45f325a7c6c8b7f9ff42cad Mon Sep 17 00:00:00 2001 +From: Petr Mladek +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 + +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 # unused next_seq warning +Cc: stable@vger.kernel.org # 5.13 +Signed-off-by: Petr Mladek +Acked-by: Sergey Senozhatsky +Reviewed-by: John Ogness +Link: https://lore.kernel.org/r/20210702150657.26760-1-pmladek@suse.com +Signed-off-by: Greg Kroah-Hartman +--- + 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()) diff --git a/queue-5.14/s390-pv-fix-the-forcing-of-the-swiotlb.patch b/queue-5.14/s390-pv-fix-the-forcing-of-the-swiotlb.patch new file mode 100644 index 00000000000..b2cd9839a70 --- /dev/null +++ b/queue-5.14/s390-pv-fix-the-forcing-of-the-swiotlb.patch @@ -0,0 +1,50 @@ +From 93ebb6828723b8aef114415c4dc3518342f7dcad Mon Sep 17 00:00:00 2001 +From: Halil Pasic +Date: Sat, 24 Jul 2021 01:17:46 +0200 +Subject: s390/pv: fix the forcing of the swiotlb + +From: Halil Pasic + +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 +Tested-by: Christian Borntraeger +Reviewed-by: Christian Borntraeger +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.14/s390-topology-fix-topology-information-when-calling-cpu-hotplug-notifiers.patch b/queue-5.14/s390-topology-fix-topology-information-when-calling-cpu-hotplug-notifiers.patch new file mode 100644 index 00000000000..366b73b1835 --- /dev/null +++ b/queue-5.14/s390-topology-fix-topology-information-when-calling-cpu-hotplug-notifiers.patch @@ -0,0 +1,134 @@ +From a052096bdd6809eeab809202726634d1ac975aa1 Mon Sep 17 00:00:00 2001 +From: Sven Schnelle +Date: Fri, 27 Aug 2021 20:21:05 +0200 +Subject: s390/topology: fix topology information when calling cpu hotplug notifiers + +From: Sven Schnelle + +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 +Cc: +[hca@linux.ibm.com: get rid of cpu_online_mask handling] +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } diff --git a/queue-5.14/scsi-buslogic-fix-missing-pr_cont-use.patch b/queue-5.14/scsi-buslogic-fix-missing-pr_cont-use.patch new file mode 100644 index 00000000000..18bc0238461 --- /dev/null +++ b/queue-5.14/scsi-buslogic-fix-missing-pr_cont-use.patch @@ -0,0 +1,108 @@ +From 44d01fc86d952f5a8b8b32bdb4841504d5833d95 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Tue, 20 Apr 2021 20:01:47 +0200 +Subject: scsi: BusLogic: Fix missing pr_cont() use + +From: Maciej W. Rozycki + +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 +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 +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 +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 +Signed-off-by: Maciej W. Rozycki +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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'); + } diff --git a/queue-5.14/scsi-qla2xxx-changes-to-support-kdump-kernel.patch b/queue-5.14/scsi-qla2xxx-changes-to-support-kdump-kernel.patch new file mode 100644 index 00000000000..bf830d2a5bc --- /dev/null +++ b/queue-5.14/scsi-qla2xxx-changes-to-support-kdump-kernel.patch @@ -0,0 +1,45 @@ +From 62e0dec59c1e139dab55aff5aa442adc97804271 Mon Sep 17 00:00:00 2001 +From: Saurav Kashyap +Date: Mon, 9 Aug 2021 21:37:17 -0700 +Subject: scsi: qla2xxx: Changes to support kdump kernel + +From: Saurav Kashyap + +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 +Signed-off-by: Saurav Kashyap +Signed-off-by: Nilesh Javali +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include ++#include + + #include + #include +@@ -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); + diff --git a/queue-5.14/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch b/queue-5.14/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch new file mode 100644 index 00000000000..d5f49ca059c --- /dev/null +++ b/queue-5.14/scsi-qla2xxx-sync-queue-idx-with-queue_pair_map-idx.patch @@ -0,0 +1,98 @@ +From c8fadf019964d0eb1da410ba8b629494d3339db9 Mon Sep 17 00:00:00 2001 +From: Saurav Kashyap +Date: Mon, 9 Aug 2021 21:37:19 -0700 +Subject: scsi: qla2xxx: Sync queue idx with queue_pair_map idx + +From: Saurav Kashyap + +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 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 +Signed-off-by: Saurav Kashyap +Signed-off-by: Nilesh Javali +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.14/series b/queue-5.14/series index 92f24abe932..6cac0c1d82c 100644 --- a/queue-5.14/series +++ b/queue-5.14/series @@ -391,3 +391,15 @@ net-fix-null-pointer-reference-in-cipso_v4_doi_free.patch 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