From: Greg Kroah-Hartman Date: Fri, 1 May 2026 11:12:15 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v6.12.86~63 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f643c012c80e35a8c48ffb69e321e5699ba6dc80;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: md-raid10-fix-deadlock-with-check-operation-and-nowait-requests.patch nvme-pci-add-nvme_quirk_disable_write_zeroes-for-kingston-om3sgp4.patch parisc-_llseek-syscall-is-only-available-for-32-bit-userspace.patch selftests-mqueue-fix-incorrectly-named-file.patch --- diff --git a/queue-5.15/md-raid10-fix-deadlock-with-check-operation-and-nowait-requests.patch b/queue-5.15/md-raid10-fix-deadlock-with-check-operation-and-nowait-requests.patch new file mode 100644 index 0000000000..6c091a23eb --- /dev/null +++ b/queue-5.15/md-raid10-fix-deadlock-with-check-operation-and-nowait-requests.patch @@ -0,0 +1,100 @@ +From 7d96f3120a7fb7210d21b520c5b6f495da6ba436 Mon Sep 17 00:00:00 2001 +From: Josh Hunt +Date: Mon, 2 Mar 2026 19:56:19 -0500 +Subject: md/raid10: fix deadlock with check operation and nowait requests + +From: Josh Hunt + +commit 7d96f3120a7fb7210d21b520c5b6f495da6ba436 upstream. + +When an array check is running it will raise the barrier at which point +normal requests will become blocked and increment the nr_pending value to +signal there is work pending inside of wait_barrier(). NOWAIT requests +do not block and so will return immediately with an error, and additionally +do not increment nr_pending in wait_barrier(). Upstream change commit +43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") added a +call to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit +this condition. raid_end_bio_io() eventually calls allow_barrier() and +it will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even +though the corresponding increment on nr_pending didn't happen in the +NOWAIT case. + +This can be easily seen by starting a check operation while an application +is doing nowait IO on the same array. This results in a deadlocked state +due to nr_pending value underflowing and so the md resync thread gets stuck +waiting for nr_pending to == 0. + +Output of r10conf state of the array when we hit this condition: + +crash> struct r10conf + barrier = 1, + nr_pending = { + counter = -41 + }, + nr_waiting = 15, + nr_queued = 0, + +Example of md_sync thread stuck waiting on raise_barrier() and other +requests stuck in wait_barrier(): + +md1_resync +[<0>] raise_barrier+0xce/0x1c0 +[<0>] raid10_sync_request+0x1ca/0x1ed0 +[<0>] md_do_sync+0x779/0x1110 +[<0>] md_thread+0x90/0x160 +[<0>] kthread+0xbe/0xf0 +[<0>] ret_from_fork+0x34/0x50 +[<0>] ret_from_fork_asm+0x1a/0x30 + +kworker/u1040:2+flush-253:4 +[<0>] wait_barrier+0x1de/0x220 +[<0>] regular_request_wait+0x30/0x180 +[<0>] raid10_make_request+0x261/0x1000 +[<0>] md_handle_request+0x13b/0x230 +[<0>] __submit_bio+0x107/0x1f0 +[<0>] submit_bio_noacct_nocheck+0x16f/0x390 +[<0>] ext4_io_submit+0x24/0x40 +[<0>] ext4_do_writepages+0x254/0xc80 +[<0>] ext4_writepages+0x84/0x120 +[<0>] do_writepages+0x7a/0x260 +[<0>] __writeback_single_inode+0x3d/0x300 +[<0>] writeback_sb_inodes+0x1dd/0x470 +[<0>] __writeback_inodes_wb+0x4c/0xe0 +[<0>] wb_writeback+0x18b/0x2d0 +[<0>] wb_workfn+0x2a1/0x400 +[<0>] process_one_work+0x149/0x330 +[<0>] worker_thread+0x2d2/0x410 +[<0>] kthread+0xbe/0xf0 +[<0>] ret_from_fork+0x34/0x50 +[<0>] ret_from_fork_asm+0x1a/0x30 + +Fixes: 43806c3d5b9b ("raid10: cleanup memleak at raid10_make_request") +Cc: stable@vger.kernel.org +Signed-off-by: Josh Hunt +Link: https://lore.kernel.org/linux-raid/20260303005619.1352958-1-johunt@akamai.com +Signed-off-by: Yu Kuai +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid10.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -1197,7 +1197,7 @@ static void raid10_read_request(struct m + } + + if (!regular_request_wait(mddev, conf, bio, r10_bio->sectors)) { +- raid_end_bio_io(r10_bio); ++ free_r10bio(r10_bio); + return; + } + +@@ -1435,7 +1435,7 @@ static void raid10_write_request(struct + + sectors = r10_bio->sectors; + if (!regular_request_wait(mddev, conf, bio, sectors)) { +- raid_end_bio_io(r10_bio); ++ free_r10bio(r10_bio); + return; + } + diff --git a/queue-5.15/nvme-pci-add-nvme_quirk_disable_write_zeroes-for-kingston-om3sgp4.patch b/queue-5.15/nvme-pci-add-nvme_quirk_disable_write_zeroes-for-kingston-om3sgp4.patch new file mode 100644 index 0000000000..95c012ad27 --- /dev/null +++ b/queue-5.15/nvme-pci-add-nvme_quirk_disable_write_zeroes-for-kingston-om3sgp4.patch @@ -0,0 +1,41 @@ +From a8eebf9699d69987cc49cec4e4fdb4111ab32423 Mon Sep 17 00:00:00 2001 +From: Robert Beckett +Date: Fri, 20 Mar 2026 19:22:09 +0000 +Subject: nvme-pci: add NVME_QUIRK_DISABLE_WRITE_ZEROES for Kingston OM3SGP4 + +From: Robert Beckett + +commit a8eebf9699d69987cc49cec4e4fdb4111ab32423 upstream. + +The Kingston OM3SGP42048K2-A00 (PCI ID 2646:502f) firmware has a race +condition when processing concurrent write zeroes and DSM (discard) +commands, causing spurious "LBA Out of Range" errors and IOMMU page +faults at address 0x0. + +The issue is reliably triggered by running two concurrent mkfs commands +on different partitions of the same drive, which generates interleaved +write zeroes and discard operations. + +Disable write zeroes for this device, matching the pattern used for +other Kingston OM* drives that have similar firmware issues. + +Cc: stable@vger.kernel.org +Signed-off-by: Robert Beckett +Assisted-by: claude-opus-4-6-v1 +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/pci.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/nvme/host/pci.c ++++ b/drivers/nvme/host/pci.c +@@ -3478,6 +3478,8 @@ static const struct pci_device_id nvme_i + .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + { PCI_DEVICE(0x2646, 0x501E), /* KINGSTON OM3PGP4xxxxQ OS21011 NVMe SSD */ + .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, ++ { PCI_DEVICE(0x2646, 0x502F), /* KINGSTON OM3SGP4xxxxK NVMe SSD */ ++ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + { PCI_DEVICE(0x1f40, 0x1202), /* Netac Technologies Co. NV3000 NVMe SSD */ + .driver_data = NVME_QUIRK_BOGUS_NID, }, + { PCI_DEVICE(0x1f40, 0x5236), /* Netac Technologies Co. NV7000 NVMe SSD */ diff --git a/queue-5.15/parisc-_llseek-syscall-is-only-available-for-32-bit-userspace.patch b/queue-5.15/parisc-_llseek-syscall-is-only-available-for-32-bit-userspace.patch new file mode 100644 index 0000000000..d36e6e5a28 --- /dev/null +++ b/queue-5.15/parisc-_llseek-syscall-is-only-available-for-32-bit-userspace.patch @@ -0,0 +1,27 @@ +From da3680f564bd787ce974f9931e6e924d908b3b2a Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Tue, 7 Apr 2026 23:56:28 +0200 +Subject: parisc: _llseek syscall is only available for 32-bit userspace + +From: Helge Deller + +commit da3680f564bd787ce974f9931e6e924d908b3b2a upstream. + +Cc: stable@vger.kernel.org +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/syscalls/syscall.tbl | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/parisc/kernel/syscalls/syscall.tbl ++++ b/arch/parisc/kernel/syscalls/syscall.tbl +@@ -154,7 +154,7 @@ + # 137 was afs_syscall + 138 common setfsuid sys_setfsuid + 139 common setfsgid sys_setfsgid +-140 common _llseek sys_llseek ++140 32 _llseek sys_llseek + 141 common getdents sys_getdents compat_sys_getdents + 142 common _newselect sys_select compat_sys_select + 143 common flock sys_flock diff --git a/queue-5.15/selftests-mqueue-fix-incorrectly-named-file.patch b/queue-5.15/selftests-mqueue-fix-incorrectly-named-file.patch new file mode 100644 index 0000000000..95a67fdced --- /dev/null +++ b/queue-5.15/selftests-mqueue-fix-incorrectly-named-file.patch @@ -0,0 +1,41 @@ +From 64fac99037689020ad97e472ae898e96ea3616dc Mon Sep 17 00:00:00 2001 +From: Simon Liebold +Date: Thu, 12 Mar 2026 14:02:00 +0000 +Subject: selftests/mqueue: Fix incorrectly named file + +From: Simon Liebold + +commit 64fac99037689020ad97e472ae898e96ea3616dc upstream. + +Commit 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") +intended to increase the timeout for mq_perf_tests from the default +kselftest limit of 45 seconds to 180 seconds. + +Unfortunately, the file storing this information was incorrectly named +`setting` instead of `settings`, causing the kselftest runner not to +pick up the limit and keep using the default 45 seconds limit. + +Fix this by renaming it to `settings` to ensure that the kselftest +runner uses the increased timeout of 180 seconds for this test. + +Fixes: 85506aca2eb4 ("selftests/mqueue: Set timeout to 180 seconds") +Cc: # 5.10.y +Signed-off-by: Simon Liebold +Link: https://lore.kernel.org/r/20260312140200.2224850-1-simonlie@amazon.de +Signed-off-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mqueue/{setting => settings} | 0 + tools/testing/selftests/mqueue/setting | 1 - + tools/testing/selftests/mqueue/settings | 1 + + 2 files changed, 1 insertion(+), 1 deletion(-) + rename tools/testing/selftests/mqueue/{setting => settings} (100%) + +--- a/tools/testing/selftests/mqueue/setting ++++ /dev/null +@@ -1 +0,0 @@ +-timeout=180 +--- /dev/null ++++ b/tools/testing/selftests/mqueue/settings +@@ -0,0 +1 @@ ++timeout=180 diff --git a/queue-5.15/series b/queue-5.15/series index a5790e8acf..97eb807744 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -210,3 +210,7 @@ ext2-reject-inodes-with-zero-i_nlink-and-valid-mode-in-ext2_iget.patch alsa-aoa-i2sbus-fix-of-node-lifetime-handling.patch alsa-ctxfi-add-fallback-to-default-rsr-for-s-pdif.patch alsa-seq_oss-return-full-count-for-successful-seq_fullsize-writes.patch +md-raid10-fix-deadlock-with-check-operation-and-nowait-requests.patch +nvme-pci-add-nvme_quirk_disable_write_zeroes-for-kingston-om3sgp4.patch +parisc-_llseek-syscall-is-only-available-for-32-bit-userspace.patch +selftests-mqueue-fix-incorrectly-named-file.patch