From: Greg Kroah-Hartman Date: Sun, 7 May 2023 10:59:30 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v5.15.111~77 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=fb1f21f8c310ea54aa0b8f1ac5ade538d48b19b2;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch kasan-hw_tags-avoid-invalid-virt_to_page.patch kcsan-avoid-read_once-in-read_instrumented_memory.patch mailbox-zynqmp-fix-ipi-isr-handling.patch mailbox-zynqmp-fix-typo-in-ipi-documentation.patch md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch md-raid5-improve-performance-for-sequential-io.patch mtd-core-fix-error-path-for-nvmem-provider.patch mtd-core-fix-nvmem-error-reporting.patch mtd-core-provide-unique-name-for-nvmem-device-take-two.patch mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch --- diff --git a/queue-6.1/clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch b/queue-6.1/clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch new file mode 100644 index 00000000000..533325de596 --- /dev/null +++ b/queue-6.1/clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch @@ -0,0 +1,52 @@ +From 7455b7007b9e93bcc2bc9c1c6c73a228e3152069 Mon Sep 17 00:00:00 2001 +From: Conor Dooley +Date: Thu, 13 Apr 2023 23:20:45 +0100 +Subject: clk: microchip: fix potential UAF in auxdev release callback + +From: Conor Dooley + +commit 7455b7007b9e93bcc2bc9c1c6c73a228e3152069 upstream. + +Similar to commit 1c11289b34ab ("peci: cpu: Fix use-after-free in +adev_release()"), the auxiliary device is not torn down in the correct +order. If auxiliary_device_add() fails, the release callback will be +called twice, resulting in a UAF. Due to timing, the auxdev code in this +driver "took inspiration" from the aforementioned commit, and thus its +bugs too! + +Moving auxiliary_device_uninit() to the unregister callback instead +avoids the issue. + +CC: stable@vger.kernel.org +Fixes: b56bae2dd6fd ("clk: microchip: mpfs: add reset controller") +Signed-off-by: Conor Dooley +Link: https://lore.kernel.org/r/20230413-critter-synopsis-dac070a86cb4@spud +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/microchip/clk-mpfs.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/clk/microchip/clk-mpfs.c b/drivers/clk/microchip/clk-mpfs.c +index 4f0a19db7ed7..cc5d7dee59f0 100644 +--- a/drivers/clk/microchip/clk-mpfs.c ++++ b/drivers/clk/microchip/clk-mpfs.c +@@ -374,14 +374,13 @@ static void mpfs_reset_unregister_adev(void *_adev) + struct auxiliary_device *adev = _adev; + + auxiliary_device_delete(adev); ++ auxiliary_device_uninit(adev); + } + + static void mpfs_reset_adev_release(struct device *dev) + { + struct auxiliary_device *adev = to_auxiliary_dev(dev); + +- auxiliary_device_uninit(adev); +- + kfree(adev); + } + +-- +2.40.1 + diff --git a/queue-6.1/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch b/queue-6.1/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch new file mode 100644 index 00000000000..143f38e5dec --- /dev/null +++ b/queue-6.1/clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch @@ -0,0 +1,39 @@ +From 933bf364e152cd60902cf9585c2ba310d593e69f Mon Sep 17 00:00:00 2001 +From: Quentin Schulz +Date: Thu, 17 Nov 2022 13:04:31 +0100 +Subject: clk: rockchip: rk3399: allow clk_cifout to force clk_cifout_src to reparent + +From: Quentin Schulz + +commit 933bf364e152cd60902cf9585c2ba310d593e69f upstream. + +clk_cifout is derived from clk_cifout_src through an integer divider +limited to 32. clk_cifout_src is a child of either cpll, gpll or npll +without any possibility of a divider of any sort. The default clock +parent is cpll. + +Let's allow clk_cifout to ask its parent clk_cifout_src to reparent in +order to find the real closest possible rate for clk_cifout and not one +derived from cpll only. + +Cc: stable@vger.kernel.org # 4.10+ +Fixes: fd8bc829336a ("clk: rockchip: fix the rk3399 cifout clock") +Signed-off-by: Quentin Schulz +Link: https://lore.kernel.org/r/20221117-rk3399-cifout-set-rate-parent-v1-0-432548d04081@theobroma-systems.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + drivers/clk/rockchip/clk-rk3399.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clk/rockchip/clk-rk3399.c ++++ b/drivers/clk/rockchip/clk-rk3399.c +@@ -1263,7 +1263,7 @@ static struct rockchip_clk_branch rk3399 + RK3399_CLKSEL_CON(56), 6, 2, MFLAGS, + RK3399_CLKGATE_CON(10), 7, GFLAGS), + +- COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, 0, ++ COMPOSITE_NOGATE(SCLK_CIF_OUT, "clk_cifout", mux_clk_cif_p, CLK_SET_RATE_PARENT, + RK3399_CLKSEL_CON(56), 5, 1, MFLAGS, 0, 5, DFLAGS), + + /* gic */ diff --git a/queue-6.1/kasan-hw_tags-avoid-invalid-virt_to_page.patch b/queue-6.1/kasan-hw_tags-avoid-invalid-virt_to_page.patch new file mode 100644 index 00000000000..3ac99175ff9 --- /dev/null +++ b/queue-6.1/kasan-hw_tags-avoid-invalid-virt_to_page.patch @@ -0,0 +1,138 @@ +From 29083fd84da576bfb3563d044f98d38e6b338f00 Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Tue, 18 Apr 2023 17:42:12 +0100 +Subject: kasan: hw_tags: avoid invalid virt_to_page() + +From: Mark Rutland + +commit 29083fd84da576bfb3563d044f98d38e6b338f00 upstream. + +When booting with 'kasan.vmalloc=off', a kernel configured with support +for KASAN_HW_TAGS will explode at boot time due to bogus use of +virt_to_page() on a vmalloc adddress. With CONFIG_DEBUG_VIRTUAL selected +this will be reported explicitly, and with or without CONFIG_DEBUG_VIRTUAL +the kernel will dereference a bogus address: + +| ------------[ cut here ]------------ +| virt_to_phys used for non-linear address: (____ptrval____) (0xffff800008000000) +| WARNING: CPU: 0 PID: 0 at arch/arm64/mm/physaddr.c:15 __virt_to_phys+0x78/0x80 +| Modules linked in: +| CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.3.0-rc3-00073-g83865133300d-dirty #4 +| Hardware name: linux,dummy-virt (DT) +| pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +| pc : __virt_to_phys+0x78/0x80 +| lr : __virt_to_phys+0x78/0x80 +| sp : ffffcd076afd3c80 +| x29: ffffcd076afd3c80 x28: 0068000000000f07 x27: ffff800008000000 +| x26: fffffbfff0000000 x25: fffffbffff000000 x24: ff00000000000000 +| x23: ffffcd076ad3c000 x22: fffffc0000000000 x21: ffff800008000000 +| x20: ffff800008004000 x19: ffff800008000000 x18: ffff800008004000 +| x17: 666678302820295f x16: ffffffffffffffff x15: 0000000000000004 +| x14: ffffcd076b009e88 x13: 0000000000000fff x12: 0000000000000003 +| x11: 00000000ffffefff x10: c0000000ffffefff x9 : 0000000000000000 +| x8 : 0000000000000000 x7 : 205d303030303030 x6 : 302e30202020205b +| x5 : ffffcd076b41d63f x4 : ffffcd076afd3827 x3 : 0000000000000000 +| x2 : 0000000000000000 x1 : ffffcd076afd3a30 x0 : 000000000000004f +| Call trace: +| __virt_to_phys+0x78/0x80 +| __kasan_unpoison_vmalloc+0xd4/0x478 +| __vmalloc_node_range+0x77c/0x7b8 +| __vmalloc_node+0x54/0x64 +| init_IRQ+0x94/0xc8 +| start_kernel+0x194/0x420 +| __primary_switched+0xbc/0xc4 +| ---[ end trace 0000000000000000 ]--- +| Unable to handle kernel paging request at virtual address 03fffacbe27b8000 +| Mem abort info: +| ESR = 0x0000000096000004 +| EC = 0x25: DABT (current EL), IL = 32 bits +| SET = 0, FnV = 0 +| EA = 0, S1PTW = 0 +| FSC = 0x04: level 0 translation fault +| Data abort info: +| ISV = 0, ISS = 0x00000004 +| CM = 0, WnR = 0 +| swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041bc5000 +| [03fffacbe27b8000] pgd=0000000000000000, p4d=0000000000000000 +| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP +| Modules linked in: +| CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.3.0-rc3-00073-g83865133300d-dirty #4 +| Hardware name: linux,dummy-virt (DT) +| pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +| pc : __kasan_unpoison_vmalloc+0xe4/0x478 +| lr : __kasan_unpoison_vmalloc+0xd4/0x478 +| sp : ffffcd076afd3ca0 +| x29: ffffcd076afd3ca0 x28: 0068000000000f07 x27: ffff800008000000 +| x26: 0000000000000000 x25: 03fffacbe27b8000 x24: ff00000000000000 +| x23: ffffcd076ad3c000 x22: fffffc0000000000 x21: ffff800008000000 +| x20: ffff800008004000 x19: ffff800008000000 x18: ffff800008004000 +| x17: 666678302820295f x16: ffffffffffffffff x15: 0000000000000004 +| x14: ffffcd076b009e88 x13: 0000000000000fff x12: 0000000000000001 +| x11: 0000800008000000 x10: ffff800008000000 x9 : ffffb2f8dee00000 +| x8 : 000ffffb2f8dee00 x7 : 205d303030303030 x6 : 302e30202020205b +| x5 : ffffcd076b41d63f x4 : ffffcd076afd3827 x3 : 0000000000000000 +| x2 : 0000000000000000 x1 : ffffcd076afd3a30 x0 : ffffb2f8dee00000 +| Call trace: +| __kasan_unpoison_vmalloc+0xe4/0x478 +| __vmalloc_node_range+0x77c/0x7b8 +| __vmalloc_node+0x54/0x64 +| init_IRQ+0x94/0xc8 +| start_kernel+0x194/0x420 +| __primary_switched+0xbc/0xc4 +| Code: d34cfc08 aa1f03fa 8b081b39 d503201f (f9400328) +| ---[ end trace 0000000000000000 ]--- +| Kernel panic - not syncing: Attempted to kill the idle task! + +This is because init_vmalloc_pages() erroneously calls virt_to_page() on +a vmalloc address, while virt_to_page() is only valid for addresses in +the linear/direct map. Since init_vmalloc_pages() expects virtual +addresses in the vmalloc range, it must use vmalloc_to_page() rather +than virt_to_page(). + +We call init_vmalloc_pages() from __kasan_unpoison_vmalloc(), where we +check !is_vmalloc_or_module_addr(), suggesting that we might encounter a +non-vmalloc address. Luckily, this never happens. By design, we only +call __kasan_unpoison_vmalloc() on pointers in the vmalloc area, and I +have verified that we don't violate that expectation. Given that, +is_vmalloc_or_module_addr() must always be true for any legitimate +argument to __kasan_unpoison_vmalloc(). + +Correct init_vmalloc_pages() to use vmalloc_to_page(), and remove the +redundant and misleading use of is_vmalloc_or_module_addr() in +__kasan_unpoison_vmalloc(). + +Link: https://lkml.kernel.org/r/20230418164212.1775741-1-mark.rutland@arm.com +Fixes: 6c2f761dad7851d8 ("kasan: fix zeroing vmalloc memory with HW_TAGS") +Signed-off-by: Mark Rutland +Cc: Alexander Potapenko +Cc: Andrey Konovalov +Cc: Andrey Ryabinin +Cc: Dmitry Vyukov +Cc: Marco Elver +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kasan/hw_tags.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/kasan/hw_tags.c ++++ b/mm/kasan/hw_tags.c +@@ -225,7 +225,7 @@ static void init_vmalloc_pages(const voi + const void *addr; + + for (addr = start; addr < start + size; addr += PAGE_SIZE) { +- struct page *page = virt_to_page(addr); ++ struct page *page = vmalloc_to_page(addr); + + clear_highpage_kasan_tagged(page); + } +@@ -237,7 +237,7 @@ void *__kasan_unpoison_vmalloc(const voi + u8 tag; + unsigned long redzone_start, redzone_size; + +- if (!kasan_vmalloc_enabled() || !is_vmalloc_or_module_addr(start)) { ++ if (!kasan_vmalloc_enabled()) { + if (flags & KASAN_VMALLOC_INIT) + init_vmalloc_pages(start, size); + return (void *)start; diff --git a/queue-6.1/kcsan-avoid-read_once-in-read_instrumented_memory.patch b/queue-6.1/kcsan-avoid-read_once-in-read_instrumented_memory.patch new file mode 100644 index 00000000000..05423842f1b --- /dev/null +++ b/queue-6.1/kcsan-avoid-read_once-in-read_instrumented_memory.patch @@ -0,0 +1,113 @@ +From 8dec88070d964bfeb4198f34cb5956d89dd1f557 Mon Sep 17 00:00:00 2001 +From: Marco Elver +Date: Thu, 9 Mar 2023 11:17:52 +0100 +Subject: kcsan: Avoid READ_ONCE() in read_instrumented_memory() + +From: Marco Elver + +commit 8dec88070d964bfeb4198f34cb5956d89dd1f557 upstream. + +Haibo Li reported: + + | Unable to handle kernel paging request at virtual address + | ffffff802a0d8d7171 + | Mem abort info:o: + | ESR = 0x9600002121 + | EC = 0x25: DABT (current EL), IL = 32 bitsts + | SET = 0, FnV = 0 0 + | EA = 0, S1PTW = 0 0 + | FSC = 0x21: alignment fault + | Data abort info:o: + | ISV = 0, ISS = 0x0000002121 + | CM = 0, WnR = 0 0 + | swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000002835200000 + | [ffffff802a0d8d71] pgd=180000005fbf9003, p4d=180000005fbf9003, + | pud=180000005fbf9003, pmd=180000005fbe8003, pte=006800002a0d8707 + | Internal error: Oops: 96000021 [#1] PREEMPT SMP + | Modules linked in: + | CPU: 2 PID: 45 Comm: kworker/u8:2 Not tainted + | 5.15.78-android13-8-g63561175bbda-dirty #1 + | ... + | pc : kcsan_setup_watchpoint+0x26c/0x6bc + | lr : kcsan_setup_watchpoint+0x88/0x6bc + | sp : ffffffc00ab4b7f0 + | x29: ffffffc00ab4b800 x28: ffffff80294fe588 x27: 0000000000000001 + | x26: 0000000000000019 x25: 0000000000000001 x24: ffffff80294fdb80 + | x23: 0000000000000000 x22: ffffffc00a70fb68 x21: ffffff802a0d8d71 + | x20: 0000000000000002 x19: 0000000000000000 x18: ffffffc00a9bd060 + | x17: 0000000000000001 x16: 0000000000000000 x15: ffffffc00a59f000 + | x14: 0000000000000001 x13: 0000000000000000 x12: ffffffc00a70faa0 + | x11: 00000000aaaaaaab x10: 0000000000000054 x9 : ffffffc00839adf8 + | x8 : ffffffc009b4cf00 x7 : 0000000000000000 x6 : 0000000000000007 + | x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffffffc00a70fb70 + | x2 : 0005ff802a0d8d71 x1 : 0000000000000000 x0 : 0000000000000000 + | Call trace: + | kcsan_setup_watchpoint+0x26c/0x6bc + | __tsan_read2+0x1f0/0x234 + | inflate_fast+0x498/0x750 + | zlib_inflate+0x1304/0x2384 + | __gunzip+0x3a0/0x45c + | gunzip+0x20/0x30 + | unpack_to_rootfs+0x2a8/0x3fc + | do_populate_rootfs+0xe8/0x11c + | async_run_entry_fn+0x58/0x1bc + | process_one_work+0x3ec/0x738 + | worker_thread+0x4c4/0x838 + | kthread+0x20c/0x258 + | ret_from_fork+0x10/0x20 + | Code: b8bfc2a8 2a0803f7 14000007 d503249f (78bfc2a8) ) + | ---[ end trace 613a943cb0a572b6 ]----- + +The reason for this is that on certain arm64 configuration since +e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when +CONFIG_LTO=y"), READ_ONCE() may be promoted to a full atomic acquire +instruction which cannot be used on unaligned addresses. + +Fix it by avoiding READ_ONCE() in read_instrumented_memory(), and simply +forcing the compiler to do the required access by casting to the +appropriate volatile type. In terms of generated code this currently +only affects architectures that do not use the default READ_ONCE() +implementation. + +The only downside is that we are not guaranteed atomicity of the access +itself, although on most architectures a plain load up to machine word +size should still be atomic (a fact the default READ_ONCE() still relies +on itself). + +Reported-by: Haibo Li +Tested-by: Haibo Li +Cc: # 5.17+ +Signed-off-by: Marco Elver +Signed-off-by: Paul E. McKenney +Signed-off-by: Greg Kroah-Hartman +--- + kernel/kcsan/core.c | 17 +++++++++++++---- + 1 file changed, 13 insertions(+), 4 deletions(-) + +--- a/kernel/kcsan/core.c ++++ b/kernel/kcsan/core.c +@@ -337,11 +337,20 @@ static void delay_access(int type) + */ + static __always_inline u64 read_instrumented_memory(const volatile void *ptr, size_t size) + { ++ /* ++ * In the below we don't necessarily need the read of the location to ++ * be atomic, and we don't use READ_ONCE(), since all we need for race ++ * detection is to observe 2 different values. ++ * ++ * Furthermore, on certain architectures (such as arm64), READ_ONCE() ++ * may turn into more complex instructions than a plain load that cannot ++ * do unaligned accesses. ++ */ + switch (size) { +- case 1: return READ_ONCE(*(const u8 *)ptr); +- case 2: return READ_ONCE(*(const u16 *)ptr); +- case 4: return READ_ONCE(*(const u32 *)ptr); +- case 8: return READ_ONCE(*(const u64 *)ptr); ++ case 1: return *(const volatile u8 *)ptr; ++ case 2: return *(const volatile u16 *)ptr; ++ case 4: return *(const volatile u32 *)ptr; ++ case 8: return *(const volatile u64 *)ptr; + default: return 0; /* Ignore; we do not diff the values. */ + } + } diff --git a/queue-6.1/mailbox-zynqmp-fix-ipi-isr-handling.patch b/queue-6.1/mailbox-zynqmp-fix-ipi-isr-handling.patch new file mode 100644 index 00000000000..07eab65de26 --- /dev/null +++ b/queue-6.1/mailbox-zynqmp-fix-ipi-isr-handling.patch @@ -0,0 +1,50 @@ +From 74ad37a30ffee3643bc34f9ca7225b20a66abaaf Mon Sep 17 00:00:00 2001 +From: Tanmay Shah +Date: Fri, 10 Mar 2023 17:24:05 -0800 +Subject: mailbox: zynqmp: Fix IPI isr handling + +From: Tanmay Shah + +commit 74ad37a30ffee3643bc34f9ca7225b20a66abaaf upstream. + +Multiple IPI channels are mapped to same interrupt handler. +Current isr implementation handles only one channel per isr. +Fix this behavior by checking isr status bit of all child +mailbox nodes. + +Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") +Signed-off-by: Tanmay Shah +Acked-by: Michal Simek +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230311012407.1292118-3-tanmay.shah@amd.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mailbox/zynqmp-ipi-mailbox.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/mailbox/zynqmp-ipi-mailbox.c ++++ b/drivers/mailbox/zynqmp-ipi-mailbox.c +@@ -152,7 +152,7 @@ static irqreturn_t zynqmp_ipi_interrupt( + struct zynqmp_ipi_message *msg; + u64 arg0, arg3; + struct arm_smccc_res res; +- int ret, i; ++ int ret, i, status = IRQ_NONE; + + (void)irq; + arg0 = SMC_IPI_MAILBOX_STATUS_ENQUIRY; +@@ -170,11 +170,11 @@ static irqreturn_t zynqmp_ipi_interrupt( + memcpy_fromio(msg->data, mchan->req_buf, + msg->len); + mbox_chan_received_data(chan, (void *)msg); +- return IRQ_HANDLED; ++ status = IRQ_HANDLED; + } + } + } +- return IRQ_NONE; ++ return status; + } + + /** diff --git a/queue-6.1/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch b/queue-6.1/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch new file mode 100644 index 00000000000..73ca4a43939 --- /dev/null +++ b/queue-6.1/mailbox-zynqmp-fix-typo-in-ipi-documentation.patch @@ -0,0 +1,34 @@ +From 79963fbfc233759bd8a43462f120d15a1bd4f4fa Mon Sep 17 00:00:00 2001 +From: Tanmay Shah +Date: Fri, 10 Mar 2023 17:24:06 -0800 +Subject: mailbox: zynqmp: Fix typo in IPI documentation + +From: Tanmay Shah + +commit 79963fbfc233759bd8a43462f120d15a1bd4f4fa upstream. + +Xilinx IPI message buffers allows 32-byte data transfer. +Fix documentation that says 12 bytes + +Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") +Signed-off-by: Tanmay Shah +Acked-by: Michal Simek +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230311012407.1292118-4-tanmay.shah@amd.com +Signed-off-by: Mathieu Poirier +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/mailbox/zynqmp-ipi-message.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/mailbox/zynqmp-ipi-message.h ++++ b/include/linux/mailbox/zynqmp-ipi-message.h +@@ -9,7 +9,7 @@ + * @data: message payload + * + * This is the structure for data used in mbox_send_message +- * the maximum length of data buffer is fixed to 12 bytes. ++ * the maximum length of data buffer is fixed to 32 bytes. + * Client is supposed to be aware of this. + */ + struct zynqmp_ipi_message { diff --git a/queue-6.1/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch b/queue-6.1/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch new file mode 100644 index 00000000000..96aa77bf734 --- /dev/null +++ b/queue-6.1/md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch @@ -0,0 +1,64 @@ +From a405c6f0229526160aa3f177f65e20c86fce84c5 Mon Sep 17 00:00:00 2001 +From: Li Nan +Date: Wed, 22 Feb 2023 12:10:00 +0800 +Subject: md/raid10: fix null-ptr-deref in raid10_sync_request + +From: Li Nan + +commit a405c6f0229526160aa3f177f65e20c86fce84c5 upstream. + +init_resync() inits mempool and sets conf->have_replacemnt at the beginning +of sync, close_sync() frees the mempool when sync is completed. + +After [1] recovery might be skipped and init_resync() is called but +close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio. + +The following is one way to reproduce the issue. + + 1) create a array, wait for resync to complete, mddev->recovery_cp is set + to MaxSector. + 2) recovery is woken and it is skipped. conf->have_replacement is set to + 0 in init_resync(). close_sync() not called. + 3) some io errors and rdev A is set to WantReplacement. + 4) a new device is added and set to A's replacement. + 5) recovery is woken, A have replacement, but conf->have_replacemnt is + 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref + occurs. + +Fix it by not calling init_resync() if recovery skipped. + +[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") +Fixes: 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") +Cc: stable@vger.kernel.org +Signed-off-by: Li Nan +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20230222041000.3341651-3-linan666@huaweicloud.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid10.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -3302,10 +3302,6 @@ static sector_t raid10_sync_request(stru + sector_t chunk_mask = conf->geo.chunk_mask; + int page_idx = 0; + +- if (!mempool_initialized(&conf->r10buf_pool)) +- if (init_resync(conf)) +- return 0; +- + /* + * Allow skipping a full rebuild for incremental assembly + * of a clean array, like RAID1 does. +@@ -3321,6 +3317,10 @@ static sector_t raid10_sync_request(stru + return mddev->dev_sectors - sector_nr; + } + ++ if (!mempool_initialized(&conf->r10buf_pool)) ++ if (init_resync(conf)) ++ return 0; ++ + skipped: + max_sector = mddev->dev_sectors; + if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) || diff --git a/queue-6.1/md-raid5-improve-performance-for-sequential-io.patch b/queue-6.1/md-raid5-improve-performance-for-sequential-io.patch new file mode 100644 index 00000000000..cfba22eb6eb --- /dev/null +++ b/queue-6.1/md-raid5-improve-performance-for-sequential-io.patch @@ -0,0 +1,124 @@ +From fc05e06e6098ca2c28f7a10da0e00aeea20fa59e Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 17 Apr 2023 19:15:37 +0200 +Subject: md/raid5: Improve performance for sequential IO + +From: Jan Kara + +commit fc05e06e6098ca2c28f7a10da0e00aeea20fa59e upstream. + +Commit 7e55c60acfbb ("md/raid5: Pivot raid5_make_request()") changed the +order in which requests for underlying disks are created. Since for +large sequential IO adding of requests frequently races with md_raid5 +thread submitting bios to underlying disks, this results in a change in +IO pattern because intermediate states of new order of request creation +result in more smaller discontiguous requests. For RAID5 on top of three +rotational disks our performance testing revealed this results in +regression in write throughput: + +iozone -a -s 131072000 -y 4 -q 8 -i 0 -i 1 -R + +before 7e55c60acfbb: + KB reclen write rewrite read reread + 131072000 4 493670 525964 524575 513384 + 131072000 8 540467 532880 512028 513703 + +after 7e55c60acfbb: + KB reclen write rewrite read reread + 131072000 4 421785 456184 531278 509248 + 131072000 8 459283 456354 528449 543834 + +To reduce the amount of discontiguous requests we can start generating +requests with the stripe with the lowest chunk offset as that has the +best chance of being adjacent to IO queued previously. This improves the +performance to: + KB reclen write rewrite read reread + 131072000 4 497682 506317 518043 514559 + 131072000 8 514048 501886 506453 504319 + +restoring big part of the regression. + +Fixes: 7e55c60acfbb ("md/raid5: Pivot raid5_make_request()") +Cc: stable@vger.kernel.org # v6.0+ +Signed-off-by: Jan Kara +Reviewed-by: Logan Gunthorpe +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20230417171537.17899-1-jack@suse.cz +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid5.c | 45 ++++++++++++++++++++++++++++++++++++++++++++- + 1 file changed, 44 insertions(+), 1 deletion(-) + +diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c +index 812a12e3e41a..4739ed891e75 100644 +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -6079,6 +6079,38 @@ static enum stripe_result make_stripe_request(struct mddev *mddev, + return ret; + } + ++/* ++ * If the bio covers multiple data disks, find sector within the bio that has ++ * the lowest chunk offset in the first chunk. ++ */ ++static sector_t raid5_bio_lowest_chunk_sector(struct r5conf *conf, ++ struct bio *bi) ++{ ++ int sectors_per_chunk = conf->chunk_sectors; ++ int raid_disks = conf->raid_disks; ++ int dd_idx; ++ struct stripe_head sh; ++ unsigned int chunk_offset; ++ sector_t r_sector = bi->bi_iter.bi_sector & ~((sector_t)RAID5_STRIPE_SECTORS(conf)-1); ++ sector_t sector; ++ ++ /* We pass in fake stripe_head to get back parity disk numbers */ ++ sector = raid5_compute_sector(conf, r_sector, 0, &dd_idx, &sh); ++ chunk_offset = sector_div(sector, sectors_per_chunk); ++ if (sectors_per_chunk - chunk_offset >= bio_sectors(bi)) ++ return r_sector; ++ /* ++ * Bio crosses to the next data disk. Check whether it's in the same ++ * chunk. ++ */ ++ dd_idx++; ++ while (dd_idx == sh.pd_idx || dd_idx == sh.qd_idx) ++ dd_idx++; ++ if (dd_idx >= raid_disks) ++ return r_sector; ++ return r_sector + sectors_per_chunk - chunk_offset; ++} ++ + static bool raid5_make_request(struct mddev *mddev, struct bio * bi) + { + DEFINE_WAIT_FUNC(wait, woken_wake_function); +@@ -6150,6 +6182,17 @@ static bool raid5_make_request(struct mddev *mddev, struct bio * bi) + } + md_account_bio(mddev, &bi); + ++ /* ++ * Lets start with the stripe with the lowest chunk offset in the first ++ * chunk. That has the best chances of creating IOs adjacent to ++ * previous IOs in case of sequential IO and thus creates the most ++ * sequential IO pattern. We don't bother with the optimization when ++ * reshaping as the performance benefit is not worth the complexity. ++ */ ++ if (likely(conf->reshape_progress == MaxSector)) ++ logical_sector = raid5_bio_lowest_chunk_sector(conf, bi); ++ s = (logical_sector - ctx.first_sector) >> RAID5_STRIPE_SHIFT(conf); ++ + add_wait_queue(&conf->wait_for_overlap, &wait); + while (1) { + res = make_stripe_request(mddev, conf, &ctx, logical_sector, +@@ -6178,7 +6221,7 @@ static bool raid5_make_request(struct mddev *mddev, struct bio * bi) + continue; + } + +- s = find_first_bit(ctx.sectors_to_do, stripe_cnt); ++ s = find_next_bit_wrap(ctx.sectors_to_do, stripe_cnt, s); + if (s == stripe_cnt) + break; + +-- +2.40.1 + diff --git a/queue-6.1/mtd-core-fix-error-path-for-nvmem-provider.patch b/queue-6.1/mtd-core-fix-error-path-for-nvmem-provider.patch new file mode 100644 index 00000000000..9711acce769 --- /dev/null +++ b/queue-6.1/mtd-core-fix-error-path-for-nvmem-provider.patch @@ -0,0 +1,60 @@ +From e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:20 +0100 +Subject: mtd: core: fix error path for nvmem provider + +From: Michael Walle + +commit e0489f6e221f5ddee6cb3bd51b992b790c5fa4b9 upstream. + +If mtd_otp_nvmem_add() fails, the partitions won't be removed +because there is simply no call to del_mtd_partitions(). +Unfortunately, add_mtd_partitions() will print all partitions to +the kernel console. If mtd_otp_nvmem_add() returns -EPROBE_DEFER +this would print the partitions multiple times to the kernel +console. Instead move mtd_otp_nvmem_add() to the beginning of the +function. + +Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-3-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -1019,10 +1019,14 @@ int mtd_device_parse_register(struct mtd + + mtd_set_dev_defaults(mtd); + ++ ret = mtd_otp_nvmem_add(mtd); ++ if (ret) ++ goto out; ++ + if (IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) { + ret = add_mtd_device(mtd); + if (ret) +- return ret; ++ goto out; + } + + /* Prefer parsed partitions over driver-provided fallback */ +@@ -1057,9 +1061,12 @@ int mtd_device_parse_register(struct mtd + register_reboot_notifier(&mtd->reboot_notifier); + } + +- ret = mtd_otp_nvmem_add(mtd); +- + out: ++ if (ret) { ++ nvmem_unregister(mtd->otp_user_nvmem); ++ nvmem_unregister(mtd->otp_factory_nvmem); ++ } ++ + if (ret && device_is_registered(&mtd->dev)) + del_mtd_device(mtd); + diff --git a/queue-6.1/mtd-core-fix-nvmem-error-reporting.patch b/queue-6.1/mtd-core-fix-nvmem-error-reporting.patch new file mode 100644 index 00000000000..33a34dde72b --- /dev/null +++ b/queue-6.1/mtd-core-fix-nvmem-error-reporting.patch @@ -0,0 +1,52 @@ +From 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:19 +0100 +Subject: mtd: core: fix nvmem error reporting + +From: Michael Walle + +commit 8bd1d24e6ca3c599dd455b0e1b22f77bab8290eb upstream. + +The master MTD will only have an associated device if +CONFIG_MTD_PARTITIONED_MASTER is set, thus we cannot use dev_err() on +mtd->dev. Instead use the parent device which is the physical flash +memory. + +Fixes: 4b361cfa8624 ("mtd: core: add OTP nvmem provider support") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-2-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -935,6 +935,7 @@ static int mtd_nvmem_fact_otp_reg_read(v + + static int mtd_otp_nvmem_add(struct mtd_info *mtd) + { ++ struct device *dev = mtd->dev.parent; + struct nvmem_device *nvmem; + ssize_t size; + int err; +@@ -948,7 +949,7 @@ static int mtd_otp_nvmem_add(struct mtd_ + nvmem = mtd_otp_nvmem_register(mtd, "user-otp", size, + mtd_nvmem_user_otp_reg_read); + if (IS_ERR(nvmem)) { +- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n"); ++ dev_err(dev, "Failed to register OTP NVMEM device\n"); + return PTR_ERR(nvmem); + } + mtd->otp_user_nvmem = nvmem; +@@ -966,7 +967,7 @@ static int mtd_otp_nvmem_add(struct mtd_ + nvmem = mtd_otp_nvmem_register(mtd, "factory-otp", size, + mtd_nvmem_fact_otp_reg_read); + if (IS_ERR(nvmem)) { +- dev_err(&mtd->dev, "Failed to register OTP NVMEM device\n"); ++ dev_err(dev, "Failed to register OTP NVMEM device\n"); + err = PTR_ERR(nvmem); + goto err; + } diff --git a/queue-6.1/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch b/queue-6.1/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch new file mode 100644 index 00000000000..9a09a45507c --- /dev/null +++ b/queue-6.1/mtd-core-provide-unique-name-for-nvmem-device-take-two.patch @@ -0,0 +1,48 @@ +From 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e Mon Sep 17 00:00:00 2001 +From: Michael Walle +Date: Wed, 8 Mar 2023 09:20:18 +0100 +Subject: mtd: core: provide unique name for nvmem device, take two + +From: Michael Walle + +commit 1cd9ceaa5282ff10ea20a7fbadde5a476a1cc99e upstream. + +Commit c048b60d39e1 ("mtd: core: provide unique name for nvmem device") +tries to give the nvmem device a unique name, but fails badly if the mtd +device doesn't have a "struct device" associated with it, i.e. if +CONFIG_MTD_PARTITIONED_MASTER is not set. This will result in the name +"(null)-user-otp", which is not unique. It seems the best we can do is +to use the compatible name together with a unique identifier added by +the nvmem subsystem by using NVMEM_DEVID_AUTO. + +Fixes: c048b60d39e1 ("mtd: core: provide unique name for nvmem device") +Cc: stable@vger.kernel.org +Signed-off-by: Michael Walle +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20230308082021.870459-1-michael@walle.cc +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/mtdcore.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/mtdcore.c ++++ b/drivers/mtd/mtdcore.c +@@ -884,8 +884,8 @@ static struct nvmem_device *mtd_otp_nvme + + /* OTP nvmem will be registered on the physical device */ + config.dev = mtd->dev.parent; +- config.name = kasprintf(GFP_KERNEL, "%s-%s", dev_name(&mtd->dev), compatible); +- config.id = NVMEM_DEVID_NONE; ++ config.name = compatible; ++ config.id = NVMEM_DEVID_AUTO; + config.owner = THIS_MODULE; + config.type = NVMEM_TYPE_OTP; + config.root_only = true; +@@ -901,7 +901,6 @@ static struct nvmem_device *mtd_otp_nvme + nvmem = NULL; + + of_node_put(np); +- kfree(config.name); + + return nvmem; + } diff --git a/queue-6.1/mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch b/queue-6.1/mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch new file mode 100644 index 00000000000..8c212c31cd2 --- /dev/null +++ b/queue-6.1/mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch @@ -0,0 +1,46 @@ +From 37513c56139b79dd43c1774513c28f8ab2b05224 Mon Sep 17 00:00:00 2001 +From: Tudor Ambarus +Date: Fri, 31 Mar 2023 07:46:04 +0000 +Subject: mtd: spi-nor: core: Update flash's current address mode when changing address mode + +From: Tudor Ambarus + +commit 37513c56139b79dd43c1774513c28f8ab2b05224 upstream. + +The bug was obswerved while reading code. There are not many users of +addr_mode_nbytes. Anyway, we should update the flash's current address +mode when changing the address mode, fix it. We don't care for now about +the set_4byte_addr_mode(nor, false) from spi_nor_restore(), as it is +used at driver remove and shutdown. + +Fixes: d7931a215063 ("mtd: spi-nor: core: Track flash's internal address mode") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230331074606.3559258-9-tudor.ambarus@linaro.org +Signed-off-by: Tudor Ambarus +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/spi-nor/core.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/spi-nor/core.c ++++ b/drivers/mtd/spi-nor/core.c +@@ -2696,6 +2696,7 @@ static int spi_nor_quad_enable(struct sp + + static int spi_nor_init(struct spi_nor *nor) + { ++ struct spi_nor_flash_parameter *params = nor->params; + int err; + + err = spi_nor_octal_dtr_enable(nor, true); +@@ -2737,9 +2738,10 @@ static int spi_nor_init(struct spi_nor * + */ + WARN_ONCE(nor->flags & SNOR_F_BROKEN_RESET, + "enabling reset hack; may not recover from unexpected reboots\n"); +- err = nor->params->set_4byte_addr_mode(nor, true); ++ err = params->set_4byte_addr_mode(nor, true); + if (err && err != -ENOTSUPP) + return err; ++ params->addr_mode_nbytes = 4; + } + + return 0; diff --git a/queue-6.1/mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch b/queue-6.1/mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch new file mode 100644 index 00000000000..e1873e70404 --- /dev/null +++ b/queue-6.1/mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch @@ -0,0 +1,43 @@ +From 4199c1719e24e73be0acc8b0146fc31ad8af9771 Mon Sep 17 00:00:00 2001 +From: Takahiro Kuwano +Date: Thu, 6 Apr 2023 15:17:45 +0900 +Subject: mtd: spi-nor: spansion: Enable JFFS2 write buffer for Infineon s25hx SEMPER flash + +From: Takahiro Kuwano + +commit 4199c1719e24e73be0acc8b0146fc31ad8af9771 upstream. + +Infineon(Cypress) SEMPER NOR flash family has on-die ECC and its program +granularity is 16-byte ECC data unit size. JFFS2 supports write buffer +mode for ECC'd NOR flash. Provide a way to clear the MTD_BIT_WRITEABLE +flag in order to enable JFFS2 write buffer mode support. + +Fixes: b6b23833fc42 ("mtd: spi-nor: spansion: Add s25hl-t/s25hs-t IDs and fixups") +Suggested-by: Tudor Ambarus +Signed-off-by: Takahiro Kuwano +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/a1cc128e094db4ec141f85bd380127598dfef17e.1680760742.git.Takahiro.Kuwano@infineon.com +Signed-off-by: Tudor Ambarus +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/spi-nor/spansion.c | 7 ++----- + 1 file changed, 2 insertions(+), 5 deletions(-) + +--- a/drivers/mtd/spi-nor/spansion.c ++++ b/drivers/mtd/spi-nor/spansion.c +@@ -249,13 +249,10 @@ static void s25hx_t_post_sfdp_fixup(stru + + static void s25hx_t_late_init(struct spi_nor *nor) + { +- struct spi_nor_flash_parameter *params = nor->params; +- + /* Fast Read 4B requires mode cycles */ +- params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8; ++ nor->params->reads[SNOR_CMD_READ_FAST].num_mode_clocks = 8; + +- /* The writesize should be ECC data unit size */ +- params->writesize = 16; ++ cypress_nor_ecc_init(nor); + } + + static struct spi_nor_fixups s25hx_t_fixups = { diff --git a/queue-6.1/series b/queue-6.1/series index 88351e076c1..ba686a8a13a 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -577,3 +577,18 @@ nilfs2-do-not-write-dirty-data-after-degenerating-to-read-only.patch nilfs2-fix-infinite-loop-in-nilfs_mdt_get_block.patch mm-do-not-reclaim-private-data-from-pinned-page.patch drbd-correctly-submit-flush-bio-on-barrier.patch +md-raid10-fix-null-ptr-deref-in-raid10_sync_request.patch +md-raid5-improve-performance-for-sequential-io.patch +kasan-hw_tags-avoid-invalid-virt_to_page.patch +mtd-core-provide-unique-name-for-nvmem-device-take-two.patch +mtd-core-fix-nvmem-error-reporting.patch +mtd-core-fix-error-path-for-nvmem-provider.patch +mtd-spi-nor-core-update-flash-s-current-address-mode-when-changing-address-mode.patch +mtd-spi-nor-spansion-enable-jffs2-write-buffer-for-infineon-s25hx-semper-flash.patch +mailbox-zynqmp-fix-ipi-isr-handling.patch +kcsan-avoid-read_once-in-read_instrumented_memory.patch +mailbox-zynqmp-fix-typo-in-ipi-documentation.patch +wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch +wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch +clk-microchip-fix-potential-uaf-in-auxdev-release-callback.patch +clk-rockchip-rk3399-allow-clk_cifout-to-force-clk_cifout_src-to-reparent.patch diff --git a/queue-6.1/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch b/queue-6.1/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch new file mode 100644 index 00000000000..0bdd4cc00be --- /dev/null +++ b/queue-6.1/wifi-rtl8xxxu-rtl8192eu-always-needs-full-init.patch @@ -0,0 +1,43 @@ +From d46e04ccd40457a0119b76e11ab64a2ad403e138 Mon Sep 17 00:00:00 2001 +From: Bitterblue Smith +Date: Mon, 13 Mar 2023 15:42:59 +0200 +Subject: wifi: rtl8xxxu: RTL8192EU always needs full init + +From: Bitterblue Smith + +commit d46e04ccd40457a0119b76e11ab64a2ad403e138 upstream. + +Always run the entire init sequence (rtl8xxxu_init_device()) for +RTL8192EU. It's what the vendor driver does too. + +This fixes a bug where the device is unable to connect after +rebooting: + +wlp3s0f3u2: send auth to ... (try 1/3) +wlp3s0f3u2: send auth to ... (try 2/3) +wlp3s0f3u2: send auth to ... (try 3/3) +wlp3s0f3u2: authentication with ... timed out + +Rebooting leaves the device powered on (partially? at least the +firmware is still running), but not really in a working state. + +Cc: stable@vger.kernel.org +Signed-off-by: Bitterblue Smith +Acked-by: Jes Sorensen +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/4eb111a9-d4c4-37d0-b376-4e202de7153c@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c ++++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c +@@ -1700,6 +1700,7 @@ struct rtl8xxxu_fileops rtl8192eu_fops = + .rx_desc_size = sizeof(struct rtl8xxxu_rxdesc24), + .has_s0s1 = 0, + .gen2_thermal_meter = 1, ++ .needs_full_init = 1, + .adda_1t_init = 0x0fc01616, + .adda_1t_path_on = 0x0fc01616, + .adda_2t_path_on_a = 0x0fc01616, diff --git a/queue-6.1/wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch b/queue-6.1/wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch new file mode 100644 index 00000000000..12ec8a81efc --- /dev/null +++ b/queue-6.1/wifi-rtw89-fix-potential-race-condition-between-napi_init-and-napi_enable.patch @@ -0,0 +1,131 @@ +From 47515664ecfbde11425dff121f298ae4499425c9 Mon Sep 17 00:00:00 2001 +From: Ping-Ke Shih +Date: Thu, 23 Mar 2023 16:28:39 +0800 +Subject: wifi: rtw89: fix potential race condition between napi_init and napi_enable + +From: Ping-Ke Shih + +commit 47515664ecfbde11425dff121f298ae4499425c9 upstream. + +A race condition can happen if netdev is registered, but NAPI isn't +initialized yet, and meanwhile user space starts the netdev that will +enable NAPI. Then, it hits BUG_ON(): + + kernel BUG at net/core/dev.c:6423! + invalid opcode: 0000 [#1] PREEMPT SMP NOPTI + CPU: 0 PID: 417 Comm: iwd Not tainted 6.2.7-slab-dirty #3 eb0f5a8a9d91 + Hardware name: LENOVO 21DL/LNVNB161216, BIOS JPCN20WW(V1.06) 09/20/2022 + RIP: 0010:napi_enable+0x3f/0x50 + Code: 48 89 c2 48 83 e2 f6 f6 81 89 08 00 00 02 74 0d 48 83 ... + RSP: 0018:ffffada1414f3548 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffffa01425802080 RCX: 0000000000000000 + RDX: 00000000000002ff RSI: ffffada14e50c614 RDI: ffffa01425808dc0 + RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 + R10: 0000000000000001 R11: 0000000000000100 R12: ffffa01425808f58 + R13: 0000000000000000 R14: ffffa01423498940 R15: 0000000000000001 + FS: 00007f5577c0a740(0000) GS:ffffa0169fc00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007f5577a19972 CR3: 0000000125a7a000 CR4: 0000000000750ef0 + PKRU: 55555554 + Call Trace: + + rtw89_pci_ops_start+0x1c/0x70 [rtw89_pci 6cbc75429515c181cbc386478d5cfb32ffc5a0f8] + rtw89_core_start+0xbe/0x160 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] + rtw89_ops_start+0x26/0x40 [rtw89_core fe07ecb874820b6d778370d4acb6ef8a37847f22] + drv_start+0x42/0x100 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] + ieee80211_do_open+0x311/0x7d0 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] + ieee80211_open+0x6a/0x90 [mac80211 c07fa22af8c3cf3f7d7ab3884ca990784d72e2d2] + __dev_open+0xe0/0x180 + __dev_change_flags+0x1da/0x250 + dev_change_flags+0x26/0x70 + do_setlink+0x37c/0x12c0 + ? ep_poll_callback+0x246/0x290 + ? __nla_validate_parse+0x61/0xd00 + ? __wake_up_common_lock+0x8f/0xd0 + +To fix this, follow Jonas' suggestion to switch the order of these +functions and move register netdev to be the last step of PCI probe. +Also, correct the error handling of rtw89_core_register_hw(). + +Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") +Cc: stable@vger.kernel.org +Reported-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> +Link: https://lore.kernel.org/linux-wireless/CAOiHx=n7EwK2B9CnBR07FVA=sEzFagb8TkS4XC_qBNq8OwcYUg@mail.gmail.com/T/#t +Suggested-by: Jonas Gorski +Tested-by: Larry Finger +Reviewed-by: Larry Finger +Signed-off-by: Ping-Ke Shih +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230323082839.20474-1-pkshih@realtek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/realtek/rtw89/core.c | 10 +++++++--- + drivers/net/wireless/realtek/rtw89/pci.c | 19 ++++++++++--------- + 2 files changed, 17 insertions(+), 12 deletions(-) + +--- a/drivers/net/wireless/realtek/rtw89/core.c ++++ b/drivers/net/wireless/realtek/rtw89/core.c +@@ -3290,18 +3290,22 @@ static int rtw89_core_register_hw(struct + ret = ieee80211_register_hw(hw); + if (ret) { + rtw89_err(rtwdev, "failed to register hw\n"); +- goto err; ++ goto err_free_supported_band; + } + + ret = rtw89_regd_init(rtwdev, rtw89_regd_notifier); + if (ret) { + rtw89_err(rtwdev, "failed to init regd\n"); +- goto err; ++ goto err_unregister_hw; + } + + return 0; + +-err: ++err_unregister_hw: ++ ieee80211_unregister_hw(hw); ++err_free_supported_band: ++ rtw89_core_clr_supported_band(rtwdev); ++ + return ret; + } + +--- a/drivers/net/wireless/realtek/rtw89/pci.c ++++ b/drivers/net/wireless/realtek/rtw89/pci.c +@@ -3828,25 +3828,26 @@ int rtw89_pci_probe(struct pci_dev *pdev + rtw89_pci_link_cfg(rtwdev); + rtw89_pci_l1ss_cfg(rtwdev); + +- ret = rtw89_core_register(rtwdev); +- if (ret) { +- rtw89_err(rtwdev, "failed to register core\n"); +- goto err_clear_resource; +- } +- + rtw89_core_napi_init(rtwdev); + + ret = rtw89_pci_request_irq(rtwdev, pdev); + if (ret) { + rtw89_err(rtwdev, "failed to request pci irq\n"); +- goto err_unregister; ++ goto err_deinit_napi; ++ } ++ ++ ret = rtw89_core_register(rtwdev); ++ if (ret) { ++ rtw89_err(rtwdev, "failed to register core\n"); ++ goto err_free_irq; + } + + return 0; + +-err_unregister: ++err_free_irq: ++ rtw89_pci_free_irq(rtwdev, pdev); ++err_deinit_napi: + rtw89_core_napi_deinit(rtwdev); +- rtw89_core_unregister(rtwdev); + err_clear_resource: + rtw89_pci_clear_resource(rtwdev, pdev); + err_declaim_pci: