From: Greg Kroah-Hartman Date: Fri, 20 Jun 2025 08:21:48 +0000 (+0200) Subject: 6.12-stable patches X-Git-Tag: v5.4.295~162 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3b80a83d363b46f15c643bf3e17cdbe184f22265;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch asoc-codecs-wcd937x-drop-unused-buck_supply.patch ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch bus-fsl-mc-fix-get-set_taildrop-command-ids.patch bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch --- diff --git a/queue-6.12/arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch b/queue-6.12/arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch new file mode 100644 index 0000000000..bfb461d257 --- /dev/null +++ b/queue-6.12/arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch @@ -0,0 +1,48 @@ +From 96e0b355883006554a0bee3697da475971d6bba8 Mon Sep 17 00:00:00 2001 +From: Ross Stutterheim +Date: Wed, 16 Apr 2025 14:50:06 +0100 +Subject: ARM: 9447/1: arm/memremap: fix arch_memremap_can_ram_remap() + +From: Ross Stutterheim + +commit 96e0b355883006554a0bee3697da475971d6bba8 upstream. + +arm/memremap: fix arch_memremap_can_ram_remap() + +commit 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure +presence of linear map") added the definition of +arch_memremap_can_ram_remap() for arm[64] specific filtering of what pages +can be used from the linear mapping. memblock_is_map_memory() was called +with the pfn of the address given to arch_memremap_can_ram_remap(); +however, memblock_is_map_memory() expects to be given an address for arm, +not a pfn. + +This results in calls to memremap() returning a newly mapped area when +it should return an address in the existing linear mapping. + +Fix this by removing the address to pfn translation and pass the +address directly. + +Fixes: 260364d112bc ("arm[64]/memremap: don't abuse pfn_valid() to ensure presence of linear map") +Signed-off-by: Ross Stutterheim +Cc: Mike Rapoport +Cc: stable@vger.kernel.org +Reviewed-by: Catalin Marinas +Reviewed-by: Linus Walleij +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mm/ioremap.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/arch/arm/mm/ioremap.c ++++ b/arch/arm/mm/ioremap.c +@@ -515,7 +515,5 @@ void __init early_ioremap_init(void) + bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size, + unsigned long flags) + { +- unsigned long pfn = PHYS_PFN(offset); +- +- return memblock_is_map_memory(pfn); ++ return memblock_is_map_memory(offset); + } diff --git a/queue-6.12/arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch b/queue-6.12/arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch new file mode 100644 index 0000000000..925bd778de --- /dev/null +++ b/queue-6.12/arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch @@ -0,0 +1,44 @@ +From 7397daf1029d5bfd3415ec8622f5179603d5702d Mon Sep 17 00:00:00 2001 +From: Andreas Kemnade +Date: Mon, 31 Mar 2025 16:44:39 +0200 +Subject: ARM: omap: pmic-cpcap: do not mess around without CPCAP or OMAP4 + +From: Andreas Kemnade + +commit 7397daf1029d5bfd3415ec8622f5179603d5702d upstream. + +The late init call just writes to omap4 registers as soon as +CONFIG_MFD_CPCAP is enabled without checking whether the +cpcap driver is actually there or the SoC is indeed an +OMAP4. +Rather do these things only with the right device combination. + +Fixes booting the BT200 with said configuration enabled and non-factory +X-Loader and probably also some surprising behavior on other devices. + +Fixes: c145649bf262 ("ARM: OMAP2+: Configure voltage controller for cpcap to low-speed") +CC: stable@vger.kernel.org +Signed-off-by: Andreas Kemnade +Reivewed-by: Tony Lindgren +Link: https://lore.kernel.org/r/20250331144439.769697-1-andreas@kemnade.info +Signed-off-by: Kevin Hilman +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mach-omap2/pmic-cpcap.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/arm/mach-omap2/pmic-cpcap.c ++++ b/arch/arm/mach-omap2/pmic-cpcap.c +@@ -264,7 +264,11 @@ int __init omap4_cpcap_init(void) + + static int __init cpcap_late_init(void) + { +- omap4_vc_set_pmic_signaling(PWRDM_POWER_RET); ++ if (!of_find_compatible_node(NULL, NULL, "motorola,cpcap")) ++ return 0; ++ ++ if (soc_is_omap443x() || soc_is_omap446x() || soc_is_omap447x()) ++ omap4_vc_set_pmic_signaling(PWRDM_POWER_RET); + + return 0; + } diff --git a/queue-6.12/arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch b/queue-6.12/arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch new file mode 100644 index 0000000000..ca5e0bb9cf --- /dev/null +++ b/queue-6.12/arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch @@ -0,0 +1,105 @@ +From 4b634918384c0f84c33aeb4dd9fd4c38e7be5ccb Mon Sep 17 00:00:00 2001 +From: Ryan Roberts +Date: Fri, 30 May 2025 16:23:47 +0100 +Subject: arm64/mm: Close theoretical race where stale TLB entry remains valid + +From: Ryan Roberts + +commit 4b634918384c0f84c33aeb4dd9fd4c38e7be5ccb upstream. + +Commit 3ea277194daa ("mm, mprotect: flush TLB if potentially racing with +a parallel reclaim leaving stale TLB entries") describes a race that, +prior to the commit, could occur between reclaim and operations such as +mprotect() when using reclaim's tlbbatch mechanism. See that commit for +details but the summary is: + +""" +Nadav Amit identified a theoritical race between page reclaim and +mprotect due to TLB flushes being batched outside of the PTL being held. + +He described the race as follows: + + CPU0 CPU1 + ---- ---- + user accesses memory using RW PTE + [PTE now cached in TLB] + try_to_unmap_one() + ==> ptep_get_and_clear() + ==> set_tlb_ubc_flush_pending() + mprotect(addr, PROT_READ) + ==> change_pte_range() + ==> [ PTE non-present - no flush ] + + user writes using cached RW PTE + ... + + try_to_unmap_flush() +""" + +The solution was to insert flush_tlb_batched_pending() in mprotect() and +friends to explcitly drain any pending reclaim TLB flushes. In the +modern version of this solution, arch_flush_tlb_batched_pending() is +called to do that synchronisation. + +arm64's tlbbatch implementation simply issues TLBIs at queue-time +(arch_tlbbatch_add_pending()), eliding the trailing dsb(ish). The +trailing dsb(ish) is finally issued in arch_tlbbatch_flush() at the end +of the batch to wait for all the issued TLBIs to complete. + +Now, the Arm ARM states: + +""" +The completion of the TLB maintenance instruction is guaranteed only by +the execution of a DSB by the observer that performed the TLB +maintenance instruction. The execution of a DSB by a different observer +does not have this effect, even if the DSB is known to be executed after +the TLB maintenance instruction is observed by that different observer. +""" + +arch_tlbbatch_add_pending() and arch_tlbbatch_flush() conform to this +requirement because they are called from the same task (either kswapd or +caller of madvise(MADV_PAGEOUT)), so either they are on the same CPU or +if the task was migrated, __switch_to() contains an extra dsb(ish). + +HOWEVER, arm64's arch_flush_tlb_batched_pending() is also implemented as +a dsb(ish). But this may be running on a CPU remote from the one that +issued the outstanding TLBIs. So there is no architectural gurantee of +synchonization. Therefore we are still vulnerable to the theoretical +race described in Commit 3ea277194daa ("mm, mprotect: flush TLB if +potentially racing with a parallel reclaim leaving stale TLB entries"). + +Fix this by flushing the entire mm in arch_flush_tlb_batched_pending(). +This aligns with what the other arches that implement the tlbbatch +feature do. + +Cc: +Fixes: 43b3dfdd0455 ("arm64: support batched/deferred tlb shootdown during page reclamation/migration") +Signed-off-by: Ryan Roberts +Link: https://lore.kernel.org/r/20250530152445.2430295-1-ryan.roberts@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/tlbflush.h | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/arch/arm64/include/asm/tlbflush.h ++++ b/arch/arm64/include/asm/tlbflush.h +@@ -330,13 +330,14 @@ static inline void arch_tlbbatch_add_pen + } + + /* +- * If mprotect/munmap/etc occurs during TLB batched flushing, we need to +- * synchronise all the TLBI issued with a DSB to avoid the race mentioned in +- * flush_tlb_batched_pending(). ++ * If mprotect/munmap/etc occurs during TLB batched flushing, we need to ensure ++ * all the previously issued TLBIs targeting mm have completed. But since we ++ * can be executing on a remote CPU, a DSB cannot guarantee this like it can ++ * for arch_tlbbatch_flush(). Our only option is to flush the entire mm. + */ + static inline void arch_flush_tlb_batched_pending(struct mm_struct *mm) + { +- dsb(ish); ++ flush_tlb_mm(mm); + } + + /* diff --git a/queue-6.12/asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch b/queue-6.12/asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch new file mode 100644 index 0000000000..6afa31b761 --- /dev/null +++ b/queue-6.12/asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch @@ -0,0 +1,53 @@ +From 63fe298652d4eda07d738bfcbbc59d1343a675ef Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 26 May 2025 11:47:03 +0200 +Subject: ASoC: codecs: wcd9375: Fix double free of regulator supplies + +From: Krzysztof Kozlowski + +commit 63fe298652d4eda07d738bfcbbc59d1343a675ef upstream. + +Driver gets regulator supplies in probe path with +devm_regulator_bulk_get(), so should not call regulator_bulk_free() in +error and remove paths to avoid double free. + +Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply") +Cc: stable@vger.kernel.org +Signed-off-by: Krzysztof Kozlowski +Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-3-0b8a2993b7d3@linaro.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/wcd937x.c | 6 +----- + 1 file changed, 1 insertion(+), 5 deletions(-) + +--- a/sound/soc/codecs/wcd937x.c ++++ b/sound/soc/codecs/wcd937x.c +@@ -2897,10 +2897,8 @@ static int wcd937x_probe(struct platform + return dev_err_probe(dev, ret, "Failed to get supplies\n"); + + ret = regulator_bulk_enable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); +- if (ret) { +- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); ++ if (ret) + return dev_err_probe(dev, ret, "Failed to enable supplies\n"); +- } + + wcd937x_dt_parse_micbias_info(dev, wcd937x); + +@@ -2936,7 +2934,6 @@ static int wcd937x_probe(struct platform + + err_disable_regulators: + regulator_bulk_disable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); +- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); + + return ret; + } +@@ -2953,7 +2950,6 @@ static void wcd937x_remove(struct platfo + pm_runtime_dont_use_autosuspend(dev); + + regulator_bulk_disable(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); +- regulator_bulk_free(WCD937X_MAX_BULK_SUPPLY, wcd937x->supplies); + } + + #if defined(CONFIG_OF) diff --git a/queue-6.12/asoc-codecs-wcd937x-drop-unused-buck_supply.patch b/queue-6.12/asoc-codecs-wcd937x-drop-unused-buck_supply.patch new file mode 100644 index 0000000000..ecef018db2 --- /dev/null +++ b/queue-6.12/asoc-codecs-wcd937x-drop-unused-buck_supply.patch @@ -0,0 +1,33 @@ +From dc59189d32fc3dbddcf418fd4b418fb61f24ade6 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Mon, 26 May 2025 11:47:02 +0200 +Subject: ASoC: codecs: wcd937x: Drop unused buck_supply + +From: Krzysztof Kozlowski + +commit dc59189d32fc3dbddcf418fd4b418fb61f24ade6 upstream. + +Last user of wcd937x_priv->buck_supply was removed in +commit 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling +for vdd-buck supply"). + +Fixes: 216d04139a6d ("ASoC: codecs: wcd937x: Remove separate handling for vdd-buck supply") +Cc: stable@vger.kernel.org +Signed-off-by: Krzysztof Kozlowski +Link: https://patch.msgid.link/20250526-b4-b4-asoc-wcd9395-vdd-px-fixes-v1-2-0b8a2993b7d3@linaro.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/wcd937x.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/sound/soc/codecs/wcd937x.c ++++ b/sound/soc/codecs/wcd937x.c +@@ -92,7 +92,6 @@ struct wcd937x_priv { + struct regmap_irq_chip *wcd_regmap_irq_chip; + struct regmap_irq_chip_data *irq_chip; + struct regulator_bulk_data supplies[WCD937X_MAX_BULK_SUPPLY]; +- struct regulator *buck_supply; + struct snd_soc_jack *jack; + unsigned long status_mask; + s32 micb_ref[WCD937X_MAX_MICBIAS]; diff --git a/queue-6.12/ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch b/queue-6.12/ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch new file mode 100644 index 0000000000..354bd2ab18 --- /dev/null +++ b/queue-6.12/ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch @@ -0,0 +1,51 @@ +From a7b3b77fd111d49f8e25624e4ea1046322a57baf Mon Sep 17 00:00:00 2001 +From: Mikko Korhonen +Date: Tue, 17 Jun 2025 09:18:41 +0300 +Subject: ata: ahci: Disallow LPM for Asus B550-F motherboard + +From: Mikko Korhonen + +commit a7b3b77fd111d49f8e25624e4ea1046322a57baf upstream. + +Asus ROG STRIX B550-F GAMING (WI-FI) motherboard has problems on some +SATA ports with at least one hard drive model (WDC WD20EFAX-68FB5N0) +when LPM is enabled. Disabling LPM solves the issue. + +Cc: stable@vger.kernel.org +Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") +Signed-off-by: Mikko Korhonen +Link: https://lore.kernel.org/r/20250617062055.784827-1-mjkorhon@gmail.com +[cassel: more detailed comment, make single line comments consistent] +Signed-off-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/ahci.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -1458,7 +1458,23 @@ static bool ahci_broken_lpm(struct pci_d + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"), + }, +- /* 320 is broken, there is no known good version yet. */ ++ /* 320 is broken, there is no known good version. */ ++ }, ++ { ++ /* ++ * AMD 500 Series Chipset SATA Controller [1022:43eb] ++ * on this motherboard timeouts on ports 5 and 6 when ++ * LPM is enabled, at least with WDC WD20EFAX-68FB5N0 ++ * hard drives. LPM with the same drive works fine on ++ * all other ports on the same controller. ++ */ ++ .matches = { ++ DMI_MATCH(DMI_BOARD_VENDOR, ++ "ASUSTeK COMPUTER INC."), ++ DMI_MATCH(DMI_BOARD_NAME, ++ "ROG STRIX B550-F GAMING (WI-FI)"), ++ }, ++ /* 3621 is broken, there is no known good version. */ + }, + { } /* terminate list */ + }; diff --git a/queue-6.12/ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch b/queue-6.12/ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch new file mode 100644 index 0000000000..d3c1772151 --- /dev/null +++ b/queue-6.12/ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch @@ -0,0 +1,94 @@ +From b5acc3628898baa63658bc4125f9525f9b3dd4f3 Mon Sep 17 00:00:00 2001 +From: Niklas Cassel +Date: Thu, 12 Jun 2025 16:17:51 +0200 +Subject: ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard + +From: Niklas Cassel + +commit b5acc3628898baa63658bc4125f9525f9b3dd4f3 upstream. + +A user has bisected a regression which causes graphical corruptions on his +screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board +type"). + +Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy +board type") makes the graphical corruptions on his screen to go away. +(Note: there are no visible messages in dmesg that indicates a problem +with AHCI.) + +The user also reports that the problem occurs regardless if there is an +HDD or an SSD connected via AHCI, so the problem is not device related. + +The devices also work fine on other motherboards, so it seems specific to +the ASUSPRO-D840SA motherboard. + +While enabling low power modes for AHCI is not supposed to affect +completely unrelated hardware, like a graphics card, it does however +allow the system to enter deeper PC-states, which could expose ACPI issues +that were previously not visible (because the system never entered these +lower power states before). + +There are previous examples where enabling LPM exposed serious BIOS/ACPI +bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series +laptops with a too old BIOS"). + +Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA +motherboard, disable LPM for this board, in order to avoid entering lower +PC-states, which triggers graphical corruptions. + +Cc: stable@vger.kernel.org +Reported-by: Andy Yang +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111 +Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") +Reviewed-by: Damien Le Moal +Reviewed-by: Hans de Goede +Link: https://lore.kernel.org/r/20250612141750.2108342-2-cassel@kernel.org +Signed-off-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/ahci.c | 19 ++++++++++++++++++- + 1 file changed, 18 insertions(+), 1 deletion(-) + +--- a/drivers/ata/ahci.c ++++ b/drivers/ata/ahci.c +@@ -1410,8 +1410,15 @@ static bool ahci_broken_suspend(struct p + + static bool ahci_broken_lpm(struct pci_dev *pdev) + { ++ /* ++ * Platforms with LPM problems. ++ * If driver_data is NULL, there is no existing BIOS version with ++ * functioning LPM. ++ * If driver_data is non-NULL, then driver_data contains the DMI BIOS ++ * build date of the first BIOS version with functioning LPM (i.e. older ++ * BIOS versions have broken LPM). ++ */ + static const struct dmi_system_id sysids[] = { +- /* Various Lenovo 50 series have LPM issues with older BIOSen */ + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), +@@ -1446,6 +1453,13 @@ static bool ahci_broken_lpm(struct pci_d + */ + .driver_data = "20180310", /* 2.35 */ + }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), ++ DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"), ++ }, ++ /* 320 is broken, there is no known good version yet. */ ++ }, + { } /* terminate list */ + }; + const struct dmi_system_id *dmi = dmi_first_match(sysids); +@@ -1455,6 +1469,9 @@ static bool ahci_broken_lpm(struct pci_d + if (!dmi) + return false; + ++ if (!dmi->driver_data) ++ return true; ++ + dmi_get_date(DMI_BIOS_DATE, &year, &month, &date); + snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date); + diff --git a/queue-6.12/ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch b/queue-6.12/ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch new file mode 100644 index 0000000000..91561e3a32 --- /dev/null +++ b/queue-6.12/ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch @@ -0,0 +1,48 @@ +From d29fc02caad7f94b62d56ee1b01c954f9c961ba7 Mon Sep 17 00:00:00 2001 +From: Tasos Sahanidis +Date: Mon, 19 May 2025 11:49:45 +0300 +Subject: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 + +From: Tasos Sahanidis + +commit d29fc02caad7f94b62d56ee1b01c954f9c961ba7 upstream. + +The controller has a hardware bug that can hard hang the system when +doing ATAPI DMAs without any trace of what happened. Depending on the +device attached, it can also prevent the system from booting. + +In this case, the system hangs when reading the ATIP from optical media +with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an +Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, +running at UDMA/33. + +The issue can be reproduced by running the same command with a cygwin +build of cdrecord on WinXP, although it requires more attempts to cause +it. The hang in that case is also resolved by forcing PIO. It doesn't +appear that VIA has produced any drivers for that OS, thus no known +workaround exists. + +HDDs attached to the controller do not suffer from any DMA issues. + +Cc: stable@vger.kernel.org +Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677 +Signed-off-by: Tasos Sahanidis +Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com +Signed-off-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/pata_via.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/ata/pata_via.c ++++ b/drivers/ata/pata_via.c +@@ -368,7 +368,8 @@ static unsigned int via_mode_filter(stru + } + + if (dev->class == ATA_DEV_ATAPI && +- dmi_check_system(no_atapi_dma_dmi_table)) { ++ (dmi_check_system(no_atapi_dma_dmi_table) || ++ config->id == PCI_DEVICE_ID_VIA_6415)) { + ata_dev_warn(dev, "controller locks up on ATAPI DMA, forcing PIO\n"); + mask &= ATA_MASK_PIO; + } diff --git a/queue-6.12/block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch b/queue-6.12/block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch new file mode 100644 index 0000000000..d6a759e5c4 --- /dev/null +++ b/queue-6.12/block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch @@ -0,0 +1,38 @@ +From f705d33c2f0353039d03e5d6f18f70467d86080e Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Wed, 11 Jun 2025 09:59:15 +0900 +Subject: block: Clear BIO_EMULATES_ZONE_APPEND flag on BIO completion + +From: Damien Le Moal + +commit f705d33c2f0353039d03e5d6f18f70467d86080e upstream. + +When blk_zone_write_plug_bio_endio() is called for a regular write BIO +used to emulate a zone append operation, that is, a BIO flagged with +BIO_EMULATES_ZONE_APPEND, the BIO operation code is restored to the +original REQ_OP_ZONE_APPEND but the BIO_EMULATES_ZONE_APPEND flag is not +cleared. Clear it to fully return the BIO to its orginal definition. + +Fixes: 9b1ce7f0c6f8 ("block: Implement zone append emulation") +Cc: stable@vger.kernel.org +Signed-off-by: Damien Le Moal +Reviewed-by: Johannes Thumshirn +Reviewed-by: Hannes Reinecke +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20250611005915.89843-1-dlemoal@kernel.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-zoned.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/block/blk-zoned.c ++++ b/block/blk-zoned.c +@@ -1240,6 +1240,7 @@ void blk_zone_write_plug_bio_endio(struc + if (bio_flagged(bio, BIO_EMULATES_ZONE_APPEND)) { + bio->bi_opf &= ~REQ_OP_MASK; + bio->bi_opf |= REQ_OP_ZONE_APPEND; ++ bio_clear_flag(bio, BIO_EMULATES_ZONE_APPEND); + } + + /* diff --git a/queue-6.12/block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch b/queue-6.12/block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch new file mode 100644 index 0000000000..ed19e55043 --- /dev/null +++ b/queue-6.12/block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch @@ -0,0 +1,70 @@ +From 961296e89dc3800e6a3abc3f5d5bb4192cf31e98 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Wed, 11 Jun 2025 08:48:46 -0600 +Subject: block: use plug request list tail for one-shot backmerge attempt + +From: Jens Axboe + +commit 961296e89dc3800e6a3abc3f5d5bb4192cf31e98 upstream. + +Previously, the block layer stored the requests in the plug list in +LIFO order. For this reason, blk_attempt_plug_merge() would check +just the head entry for a back merge attempt, and abort after that +unless requests for multiple queues existed in the plug list. If more +than one request is present in the plug list, this makes the one-shot +back merging less useful than before, as it'll always fail to find a +quick merge candidate. + +Use the tail entry for the one-shot merge attempt, which is the last +added request in the list. If that fails, abort immediately unless +there are multiple queues available. If multiple queues are available, +then scan the list. Ideally the latter scan would be a backwards scan +of the list, but as it currently stands, the plug list is singly linked +and hence this isn't easily feasible. + +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/linux-block/20250611121626.7252-1-abuehaze@amazon.com/ +Reported-by: Hazem Mohamed Abuelfotoh +Fixes: e70c301faece ("block: don't reorder requests in blk_add_rq_to_plug") +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-merge.c | 26 +++++++++++++------------- + 1 file changed, 13 insertions(+), 13 deletions(-) + +--- a/block/blk-merge.c ++++ b/block/blk-merge.c +@@ -1180,20 +1180,20 @@ bool blk_attempt_plug_merge(struct reque + if (!plug || rq_list_empty(&plug->mq_list)) + return false; + +- rq_list_for_each(&plug->mq_list, rq) { +- if (rq->q == q) { +- if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == +- BIO_MERGE_OK) +- return true; +- break; +- } ++ rq = plug->mq_list.tail; ++ if (rq->q == q) ++ return blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == ++ BIO_MERGE_OK; ++ else if (!plug->multiple_queues) ++ return false; + +- /* +- * Only keep iterating plug list for merges if we have multiple +- * queues +- */ +- if (!plug->multiple_queues) +- break; ++ rq_list_for_each(&plug->mq_list, rq) { ++ if (rq->q != q) ++ continue; ++ if (blk_attempt_bio_merge(q, rq, bio, nr_segs, false) == ++ BIO_MERGE_OK) ++ return true; ++ break; + } + return false; + } diff --git a/queue-6.12/bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch b/queue-6.12/bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch new file mode 100644 index 0000000000..ccde3582ff --- /dev/null +++ b/queue-6.12/bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch @@ -0,0 +1,62 @@ +From 66db876162155c1cec87359cd78c62aaafde9257 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Wed, 7 May 2025 11:21:22 +0200 +Subject: bus: firewall: Fix missing static inline annotations for stubs + +From: Krzysztof Kozlowski + +commit 66db876162155c1cec87359cd78c62aaafde9257 upstream. + +Stubs in the header file for !CONFIG_STM32_FIREWALL case should be both +static and inline, because they do not come with earlier declaration and +should be inlined in every unit including the header. + +Cc: Patrice Chotard +Cc: stable@vger.kernel.org +Fixes: 5c9668cfc6d7 ("firewall: introduce stm32_firewall framework") +Link: https://lore.kernel.org/r/20250507092121.95121-2-krzysztof.kozlowski@linaro.org +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/bus/stm32_firewall_device.h | 15 +++++++++------ + 1 file changed, 9 insertions(+), 6 deletions(-) + +--- a/include/linux/bus/stm32_firewall_device.h ++++ b/include/linux/bus/stm32_firewall_device.h +@@ -114,27 +114,30 @@ void stm32_firewall_release_access_by_id + + #else /* CONFIG_STM32_FIREWALL */ + +-int stm32_firewall_get_firewall(struct device_node *np, struct stm32_firewall *firewall, +- unsigned int nb_firewall) ++static inline int stm32_firewall_get_firewall(struct device_node *np, ++ struct stm32_firewall *firewall, ++ unsigned int nb_firewall) + { + return -ENODEV; + } + +-int stm32_firewall_grant_access(struct stm32_firewall *firewall) ++static inline int stm32_firewall_grant_access(struct stm32_firewall *firewall) + { + return -ENODEV; + } + +-void stm32_firewall_release_access(struct stm32_firewall *firewall) ++static inline void stm32_firewall_release_access(struct stm32_firewall *firewall) + { + } + +-int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id) ++static inline int stm32_firewall_grant_access_by_id(struct stm32_firewall *firewall, ++ u32 subsystem_id) + { + return -ENODEV; + } + +-void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, u32 subsystem_id) ++static inline void stm32_firewall_release_access_by_id(struct stm32_firewall *firewall, ++ u32 subsystem_id) + { + } + diff --git a/queue-6.12/bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch b/queue-6.12/bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch new file mode 100644 index 0000000000..5fbd1a252d --- /dev/null +++ b/queue-6.12/bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch @@ -0,0 +1,60 @@ +From dd7d8e012b23de158ca0188239c7a1f2a83b4484 Mon Sep 17 00:00:00 2001 +From: Ioana Ciornei +Date: Tue, 8 Apr 2025 13:58:10 +0300 +Subject: bus: fsl-mc: do not add a device-link for the UAPI used DPMCP device + +From: Ioana Ciornei + +commit dd7d8e012b23de158ca0188239c7a1f2a83b4484 upstream. + +The fsl-mc bus associated to the root DPRC in a DPAA2 system exports a +device file for userspace access to the MC firmware. In case the DPRC's +local MC portal (DPMCP) is currently in use, a new DPMCP device is +allocated through the fsl_mc_portal_allocate() function. + +In this case, the call to fsl_mc_portal_allocate() will fail with -EINVAL +when trying to add a device link between the root DPRC (consumer) and +the newly allocated DPMCP device (supplier). This is because the DPMCP +is a dependent of the DPRC device (the bus). + +Fix this by not adding a device link in case the DPMCP is allocated for +the root DPRC's usage. + +Fixes: afb77422819f ("bus: fsl-mc: automatically add a device_link on fsl_mc_[portal,object]_allocate") +Signed-off-by: Ioana Ciornei +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250408105814.2837951-3-ioana.ciornei@nxp.com +Signed-off-by: Christophe Leroy +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/fsl-mc/mc-io.c | 19 +++++++++++++------ + 1 file changed, 13 insertions(+), 6 deletions(-) + +--- a/drivers/bus/fsl-mc/mc-io.c ++++ b/drivers/bus/fsl-mc/mc-io.c +@@ -214,12 +214,19 @@ int __must_check fsl_mc_portal_allocate( + if (error < 0) + goto error_cleanup_resource; + +- dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev, +- &dpmcp_dev->dev, +- DL_FLAG_AUTOREMOVE_CONSUMER); +- if (!dpmcp_dev->consumer_link) { +- error = -EINVAL; +- goto error_cleanup_mc_io; ++ /* If the DPRC device itself tries to allocate a portal (usually for ++ * UAPI interaction), don't add a device link between them since the ++ * DPMCP device is an actual child device of the DPRC and a reverse ++ * dependency is not allowed. ++ */ ++ if (mc_dev != mc_bus_dev) { ++ dpmcp_dev->consumer_link = device_link_add(&mc_dev->dev, ++ &dpmcp_dev->dev, ++ DL_FLAG_AUTOREMOVE_CONSUMER); ++ if (!dpmcp_dev->consumer_link) { ++ error = -EINVAL; ++ goto error_cleanup_mc_io; ++ } + } + + *new_mc_io = mc_io; diff --git a/queue-6.12/bus-fsl-mc-fix-get-set_taildrop-command-ids.patch b/queue-6.12/bus-fsl-mc-fix-get-set_taildrop-command-ids.patch new file mode 100644 index 0000000000..8062501fce --- /dev/null +++ b/queue-6.12/bus-fsl-mc-fix-get-set_taildrop-command-ids.patch @@ -0,0 +1,43 @@ +From c78230ad34f82c6c0e0e986865073aeeef1f5d30 Mon Sep 17 00:00:00 2001 +From: Wan Junjie +Date: Tue, 8 Apr 2025 13:58:11 +0300 +Subject: bus: fsl-mc: fix GET/SET_TAILDROP command ids + +From: Wan Junjie + +commit c78230ad34f82c6c0e0e986865073aeeef1f5d30 upstream. + +Command ids for taildrop get/set can not pass the check when they are +using from the restool user space utility. Correct them according to the +user manual. + +Fixes: d67cc29e6d1f ("bus: fsl-mc: list more commands as accepted through the ioctl") +Signed-off-by: Wan Junjie +Signed-off-by: Ioana Ciornei +Cc: stable@vger.kernel.org +Reviewed-by: Ioana Ciornei +Link: https://lore.kernel.org/r/20250408105814.2837951-4-ioana.ciornei@nxp.com +Signed-off-by: Christophe Leroy +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/fsl-mc/fsl-mc-uapi.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/bus/fsl-mc/fsl-mc-uapi.c ++++ b/drivers/bus/fsl-mc/fsl-mc-uapi.c +@@ -275,13 +275,13 @@ static struct fsl_mc_cmd_desc fsl_mc_acc + .size = 8, + }, + [DPSW_GET_TAILDROP] = { +- .cmdid_value = 0x0A80, ++ .cmdid_value = 0x0A90, + .cmdid_mask = 0xFFF0, + .token = true, + .size = 14, + }, + [DPSW_SET_TAILDROP] = { +- .cmdid_value = 0x0A90, ++ .cmdid_value = 0x0A80, + .cmdid_mask = 0xFFF0, + .token = true, + .size = 24, diff --git a/queue-6.12/bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch b/queue-6.12/bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch new file mode 100644 index 0000000000..d6ce072dac --- /dev/null +++ b/queue-6.12/bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch @@ -0,0 +1,65 @@ +From 6f18d174b73d0ceeaa341f46c0986436b3aefc9a Mon Sep 17 00:00:00 2001 +From: Sumit Kumar +Date: Wed, 9 Apr 2025 16:17:43 +0530 +Subject: bus: mhi: ep: Update read pointer only after buffer is written + +From: Sumit Kumar + +commit 6f18d174b73d0ceeaa341f46c0986436b3aefc9a upstream. + +Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated +before the buffer is written, potentially causing race conditions where +the host sees an updated read pointer before the buffer is actually +written. Updating rd_offset prematurely can lead to the host accessing +an uninitialized or incomplete element, resulting in data corruption. + +Invoke the buffer write before updating rd_offset to ensure the element +is fully written before signaling its availability. + +Fixes: bbdcba57a1a2 ("bus: mhi: ep: Add support for ring management") +cc: stable@vger.kernel.org +Co-developed-by: Youssef Samir +Signed-off-by: Youssef Samir +Signed-off-by: Sumit Kumar +Reviewed-by: Jeff Hugo +Reviewed-by: Krishna Chaitanya Chundru +Reviewed-by: Manivannan Sadhasivam +Link: https://patch.msgid.link/20250409-rp_fix-v1-1-8cf1fa22ed28@quicinc.com +Signed-off-by: Manivannan Sadhasivam +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/mhi/ep/ring.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/drivers/bus/mhi/ep/ring.c ++++ b/drivers/bus/mhi/ep/ring.c +@@ -131,19 +131,23 @@ int mhi_ep_ring_add_element(struct mhi_e + } + + old_offset = ring->rd_offset; +- mhi_ep_ring_inc_index(ring); + + dev_dbg(dev, "Adding an element to ring at offset (%zu)\n", ring->rd_offset); ++ buf_info.host_addr = ring->rbase + (old_offset * sizeof(*el)); ++ buf_info.dev_addr = el; ++ buf_info.size = sizeof(*el); ++ ++ ret = mhi_cntrl->write_sync(mhi_cntrl, &buf_info); ++ if (ret) ++ return ret; ++ ++ mhi_ep_ring_inc_index(ring); + + /* Update rp in ring context */ + rp = cpu_to_le64(ring->rd_offset * sizeof(*el) + ring->rbase); + memcpy_toio((void __iomem *) &ring->ring_ctx->generic.rp, &rp, sizeof(u64)); + +- buf_info.host_addr = ring->rbase + (old_offset * sizeof(*el)); +- buf_info.dev_addr = el; +- buf_info.size = sizeof(*el); +- +- return mhi_cntrl->write_sync(mhi_cntrl, &buf_info); ++ return ret; + } + + void mhi_ep_ring_init(struct mhi_ep_ring *ring, enum mhi_ep_ring_type type, u32 id) diff --git a/queue-6.12/bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch b/queue-6.12/bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch new file mode 100644 index 0000000000..8b654428e3 --- /dev/null +++ b/queue-6.12/bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch @@ -0,0 +1,96 @@ +From 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 Mon Sep 17 00:00:00 2001 +From: Jeffrey Hugo +Date: Fri, 28 Mar 2025 10:35:26 -0600 +Subject: bus: mhi: host: Fix conflict between power_up and SYSERR + +From: Jeff Hugo + +commit 4d92e7c5ccadc79764674ffc2c88d329aabbb7e0 upstream. + +When mhi_async_power_up() enables IRQs, it is possible that we could +receive a SYSERR notification from the device if the firmware has crashed +for some reason. Then the SYSERR notification queues a work item that +cannot execute until the pm_mutex is released by mhi_async_power_up(). + +So the SYSERR work item will be pending. If mhi_async_power_up() detects +the SYSERR, it will handle it. If the device is in PBL, then the PBL state +transition event will be queued, resulting in a work item after the +pending SYSERR work item. Once mhi_async_power_up() releases the pm_mutex, +the SYSERR work item can run. It will blindly attempt to reset the MHI +state machine, which is the recovery action for SYSERR. PBL/SBL are not +interrupt driven and will ignore the MHI Reset unless SYSERR is actively +advertised. This will cause the SYSERR work item to timeout waiting for +reset to be cleared, and will leave the host state in SYSERR processing. +The PBL transition work item will then run, and immediately fail because +SYSERR processing is not a valid state for PBL transition. + +This leaves the device uninitialized. + +This issue has a fairly unique signature in the kernel log: + + mhi mhi3: Requested to power ON + Qualcomm Cloud AI 100 0000:36:00.0: Fatal error received from + device. Attempting to recover + mhi mhi3: Power on setup success + mhi mhi3: Device failed to exit MHI Reset state + mhi mhi3: Device MHI is not in valid state + +We cannot remove the SYSERR handling from mhi_async_power_up() because the +device may be in the SYSERR state, but we missed the notification as the +irq was fired before irqs were enabled. We also can't queue the SYSERR work +item from mhi_async_power_up() if SYSERR is detected because that may +result in a duplicate work item, and cause the same issue since the +duplicate item will blindly issue MHI reset even if SYSERR is no longer +active. + +Instead, add a check in the SYSERR work item to make sure that MHI reset is +only issued if the device is in SYSERR state for PBL or SBL EEs. + +Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions") +Signed-off-by: Jeffrey Hugo +Signed-off-by: Jeff Hugo +Signed-off-by: Manivannan Sadhasivam +Reviewed-by: Troy Hanson +Reviewed-by: Manivannan Sadhasivam +cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20250328163526.3365497-1-jeff.hugo@oss.qualcomm.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/bus/mhi/host/pm.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/bus/mhi/host/pm.c ++++ b/drivers/bus/mhi/host/pm.c +@@ -602,6 +602,7 @@ static void mhi_pm_sys_error_transition( + struct mhi_cmd *mhi_cmd; + struct mhi_event_ctxt *er_ctxt; + struct device *dev = &mhi_cntrl->mhi_dev->dev; ++ bool reset_device = false; + int ret, i; + + dev_dbg(dev, "Transitioning from PM state: %s to: %s\n", +@@ -630,8 +631,23 @@ static void mhi_pm_sys_error_transition( + /* Wake up threads waiting for state transition */ + wake_up_all(&mhi_cntrl->state_event); + +- /* Trigger MHI RESET so that the device will not access host memory */ + if (MHI_REG_ACCESS_VALID(prev_state)) { ++ /* ++ * If the device is in PBL or SBL, it will only respond to ++ * RESET if the device is in SYSERR state. SYSERR might ++ * already be cleared at this point. ++ */ ++ enum mhi_state cur_state = mhi_get_mhi_state(mhi_cntrl); ++ enum mhi_ee_type cur_ee = mhi_get_exec_env(mhi_cntrl); ++ ++ if (cur_state == MHI_STATE_SYS_ERR) ++ reset_device = true; ++ else if (cur_ee != MHI_EE_PBL && cur_ee != MHI_EE_SBL) ++ reset_device = true; ++ } ++ ++ /* Trigger MHI RESET so that the device will not access host memory */ ++ if (reset_device) { + u32 in_reset = -1; + unsigned long timeout = msecs_to_jiffies(mhi_cntrl->timeout_ms); + diff --git a/queue-6.12/can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch b/queue-6.12/can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch new file mode 100644 index 0000000000..029c780588 --- /dev/null +++ b/queue-6.12/can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch @@ -0,0 +1,87 @@ +From 54ec8b08216f3be2cc98b33633d3c8ea79749895 Mon Sep 17 00:00:00 2001 +From: Fedor Pchelkin +Date: Wed, 28 May 2025 22:27:12 +0300 +Subject: can: kvaser_pciefd: refine error prone echo_skb_max handling logic + +From: Fedor Pchelkin + +commit 54ec8b08216f3be2cc98b33633d3c8ea79749895 upstream. + +echo_skb_max should define the supported upper limit of echo_skb[] +allocated inside the netdevice's priv. The corresponding size value +provided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNT +which is 17. + +But later echo_skb_max is rounded up to the nearest power of two (for the +max case, that would be 32) and the tx/ack indices calculated further +during tx/rx may exceed the upper array boundary. Kasan reported this for +the ack case inside kvaser_pciefd_handle_ack_packet(), though the xmit +function has actually caught the same thing earlier. + + BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 + Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 + + CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) + Call Trace: + + dump_stack_lvl lib/dump_stack.c:122 + print_report mm/kasan/report.c:521 + kasan_report mm/kasan/report.c:634 + kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 + kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 + kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 + kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 + kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 + __handle_irq_event_percpu kernel/irq/handle.c:158 + handle_irq_event kernel/irq/handle.c:210 + handle_edge_irq kernel/irq/chip.c:833 + __common_interrupt arch/x86/kernel/irq.c:296 + common_interrupt arch/x86/kernel/irq.c:286 + + +Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seq +numbers' generation that's not the case - we're free to calculate them as +would be more convenient, not taking tx max count into account. The only +downside is that the size of echo_skb[] should correspond to the max seq +number (not tx max count), so in some situations a bit more memory would +be consumed than could be. + +Thus make the size of the underlying echo_skb[] sufficient for the rounded +max tx value. + +Found by Linux Verification Center (linuxtesting.org) with Syzkaller. + +Fixes: 8256e0ca6010 ("can: kvaser_pciefd: Fix echo_skb race") +Cc: stable@vger.kernel.org +Signed-off-by: Fedor Pchelkin +Link: https://patch.msgid.link/20250528192713.63894-1-pchelkin@ispras.ru +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/kvaser_pciefd.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/net/can/kvaser_pciefd.c b/drivers/net/can/kvaser_pciefd.c +index 7d3066691d5d..52301511ed1b 100644 +--- a/drivers/net/can/kvaser_pciefd.c ++++ b/drivers/net/can/kvaser_pciefd.c +@@ -966,7 +966,7 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie) + u32 status, tx_nr_packets_max; + + netdev = alloc_candev(sizeof(struct kvaser_pciefd_can), +- KVASER_PCIEFD_CAN_TX_MAX_COUNT); ++ roundup_pow_of_two(KVASER_PCIEFD_CAN_TX_MAX_COUNT)); + if (!netdev) + return -ENOMEM; + +@@ -995,7 +995,6 @@ static int kvaser_pciefd_setup_can_ctrls(struct kvaser_pciefd *pcie) + can->tx_max_count = min(KVASER_PCIEFD_CAN_TX_MAX_COUNT, tx_nr_packets_max - 1); + + can->can.clock.freq = pcie->freq; +- can->can.echo_skb_max = roundup_pow_of_two(can->tx_max_count); + spin_lock_init(&can->lock); + + can->can.bittiming_const = &kvaser_pciefd_bittiming_const; +-- +2.50.0 + diff --git a/queue-6.12/can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch b/queue-6.12/can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch new file mode 100644 index 0000000000..d28617ccaa --- /dev/null +++ b/queue-6.12/can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch @@ -0,0 +1,41 @@ +From db22720545207f734aaa9d9f71637bfc8b0155e0 Mon Sep 17 00:00:00 2001 +From: Brett Werling +Date: Thu, 12 Jun 2025 14:18:25 -0500 +Subject: can: tcan4x5x: fix power regulator retrieval during probe + +From: Brett Werling + +commit db22720545207f734aaa9d9f71637bfc8b0155e0 upstream. + +Fixes the power regulator retrieval in tcan4x5x_can_probe() by ensuring +the regulator pointer is not set to NULL in the successful return from +devm_regulator_get_optional(). + +Fixes: 3814ca3a10be ("can: tcan4x5x: tcan4x5x_can_probe(): turn on the power before parsing the config") +Signed-off-by: Brett Werling +Link: https://patch.msgid.link/20250612191825.3646364-1-brett.werling@garmin.com +Cc: stable@vger.kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/m_can/tcan4x5x-core.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/net/can/m_can/tcan4x5x-core.c ++++ b/drivers/net/can/m_can/tcan4x5x-core.c +@@ -385,10 +385,11 @@ static int tcan4x5x_can_probe(struct spi + priv = cdev_to_priv(mcan_class); + + priv->power = devm_regulator_get_optional(&spi->dev, "vsup"); +- if (PTR_ERR(priv->power) == -EPROBE_DEFER) { +- ret = -EPROBE_DEFER; +- goto out_m_can_class_free_dev; +- } else { ++ if (IS_ERR(priv->power)) { ++ if (PTR_ERR(priv->power) == -EPROBE_DEFER) { ++ ret = -EPROBE_DEFER; ++ goto out_m_can_class_free_dev; ++ } + priv->power = NULL; + } + diff --git a/queue-6.12/ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch b/queue-6.12/ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch new file mode 100644 index 0000000000..628fb4da3c --- /dev/null +++ b/queue-6.12/ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch @@ -0,0 +1,179 @@ +From 060909278cc0a91373a20726bd3d8ce085f480a9 Mon Sep 17 00:00:00 2001 +From: Viacheslav Dubeyko +Date: Thu, 16 Jan 2025 16:30:08 -0800 +Subject: ceph: avoid kernel BUG for encrypted inode with unaligned file size + +From: Viacheslav Dubeyko + +commit 060909278cc0a91373a20726bd3d8ce085f480a9 upstream. + +The generic/397 test hits a BUG_ON for the case of encrypted inode with +unaligned file size (for example, 33K or 1K): + +[ 877.737811] run fstests generic/397 at 2025-01-03 12:34:40 +[ 877.875761] libceph: mon0 (2)127.0.0.1:40674 session established +[ 877.876130] libceph: client4614 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 877.991965] libceph: mon0 (2)127.0.0.1:40674 session established +[ 877.992334] libceph: client4617 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 878.017234] libceph: mon0 (2)127.0.0.1:40674 session established +[ 878.017594] libceph: client4620 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 878.031394] xfs_io (pid 18988) is setting deprecated v1 encryption policy; recommend upgrading to v2. +[ 878.054528] libceph: mon0 (2)127.0.0.1:40674 session established +[ 878.054892] libceph: client4623 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 878.070287] libceph: mon0 (2)127.0.0.1:40674 session established +[ 878.070704] libceph: client4626 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 878.264586] libceph: mon0 (2)127.0.0.1:40674 session established +[ 878.265258] libceph: client4629 fsid 19b90bca-f1ae-47a6-93dd-0b03ee637949 +[ 878.374578] -----------[ cut here ]------------ +[ 878.374586] kernel BUG at net/ceph/messenger.c:1070! +[ 878.375150] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +[ 878.378145] CPU: 2 UID: 0 PID: 4759 Comm: kworker/2:9 Not tainted 6.13.0-rc5+ #1 +[ 878.378969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 +[ 878.380167] Workqueue: ceph-msgr ceph_con_workfn +[ 878.381639] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50 +[ 878.382152] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 +[ 878.383928] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287 +[ 878.384447] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000 +[ 878.385129] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378 +[ 878.385839] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000 +[ 878.386539] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030 +[ 878.387203] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001 +[ 878.387877] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000 +[ 878.388663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 878.389212] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0 +[ 878.389921] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 878.390620] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 878.391307] PKRU: 55555554 +[ 878.391567] Call Trace: +[ 878.391807] +[ 878.392021] ? show_regs+0x71/0x90 +[ 878.392391] ? die+0x38/0xa0 +[ 878.392667] ? do_trap+0xdb/0x100 +[ 878.392981] ? do_error_trap+0x75/0xb0 +[ 878.393372] ? ceph_msg_data_cursor_init+0x42/0x50 +[ 878.393842] ? exc_invalid_op+0x53/0x80 +[ 878.394232] ? ceph_msg_data_cursor_init+0x42/0x50 +[ 878.394694] ? asm_exc_invalid_op+0x1b/0x20 +[ 878.395099] ? ceph_msg_data_cursor_init+0x42/0x50 +[ 878.395583] ? ceph_con_v2_try_read+0xd16/0x2220 +[ 878.396027] ? _raw_spin_unlock+0xe/0x40 +[ 878.396428] ? raw_spin_rq_unlock+0x10/0x40 +[ 878.396842] ? finish_task_switch.isra.0+0x97/0x310 +[ 878.397338] ? __schedule+0x44b/0x16b0 +[ 878.397738] ceph_con_workfn+0x326/0x750 +[ 878.398121] process_one_work+0x188/0x3d0 +[ 878.398522] ? __pfx_worker_thread+0x10/0x10 +[ 878.398929] worker_thread+0x2b5/0x3c0 +[ 878.399310] ? __pfx_worker_thread+0x10/0x10 +[ 878.399727] kthread+0xe1/0x120 +[ 878.400031] ? __pfx_kthread+0x10/0x10 +[ 878.400431] ret_from_fork+0x43/0x70 +[ 878.400771] ? __pfx_kthread+0x10/0x10 +[ 878.401127] ret_from_fork_asm+0x1a/0x30 +[ 878.401543] +[ 878.401760] Modules linked in: hctr2 nhpoly1305_avx2 nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 essiv authenc mptcp_diag xsk_diag tcp_diag udp_diag raw_diag inet_diag unix_diag af_packet_diag netlink_diag intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha256_ssse3 sha1_ssse3 aesni_intel joydev crypto_simd cryptd rapl input_leds psmouse sch_fq_codel serio_raw bochs i2c_piix4 floppy qemu_fw_cfg i2c_smbus mac_hid pata_acpi msr parport_pc ppdev lp parport efi_pstore ip_tables x_tables +[ 878.407319] ---[ end trace 0000000000000000 ]--- +[ 878.407775] RIP: 0010:ceph_msg_data_cursor_init+0x42/0x50 +[ 878.408317] Code: 89 17 48 8b 46 70 55 48 89 47 08 c7 47 18 00 00 00 00 48 89 e5 e8 de cc ff ff 5d 31 c0 31 d2 31 f6 31 ff c3 cc cc cc cc 0f 0b <0f> 0b 0f 0b 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 +[ 878.410087] RSP: 0018:ffffb4ffc7cbbd28 EFLAGS: 00010287 +[ 878.410609] RAX: ffffffff82bb9ac0 RBX: ffff981390c2f1f8 RCX: 0000000000000000 +[ 878.411318] RDX: 0000000000009000 RSI: ffff981288232b58 RDI: ffff981390c2f378 +[ 878.412014] RBP: ffffb4ffc7cbbe18 R08: 0000000000000000 R09: 0000000000000000 +[ 878.412735] R10: 0000000000000000 R11: 0000000000000000 R12: ffff981390c2f030 +[ 878.413438] R13: ffff981288232b58 R14: 0000000000000029 R15: 0000000000000001 +[ 878.414121] FS: 0000000000000000(0000) GS:ffff9814b7900000(0000) knlGS:0000000000000000 +[ 878.414935] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 878.415516] CR2: 00005e106a0554e0 CR3: 0000000112bf0001 CR4: 0000000000772ef0 +[ 878.416211] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 878.416907] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 878.417630] PKRU: 55555554 + +(gdb) l *ceph_msg_data_cursor_init+0x42 +0xffffffff823b45a2 is in ceph_msg_data_cursor_init (net/ceph/messenger.c:1070). +1065 +1066 void ceph_msg_data_cursor_init(struct ceph_msg_data_cursor *cursor, +1067 struct ceph_msg *msg, size_t length) +1068 { +1069 BUG_ON(!length); +1070 BUG_ON(length > msg->data_length); +1071 BUG_ON(!msg->num_data_items); +1072 +1073 cursor->total_resid = length; +1074 cursor->data = msg->data; + +The issue takes place because of this: + +[ 202.628853] libceph: net/ceph/messenger_v2.c:2034 prepare_sparse_read_data(): msg->data_length 33792, msg->sparse_read_total 36864 + +1070 BUG_ON(length > msg->data_length); + +The generic/397 test (xfstests) executes such steps: +(1) create encrypted files and directories; +(2) access the created files and folders with encryption key; +(3) access the created files and folders without encryption key. + +The issue takes place in this portion of code: + + if (IS_ENCRYPTED(inode)) { + struct page **pages; + size_t page_off; + + err = iov_iter_get_pages_alloc2(&subreq->io_iter, &pages, len, + &page_off); + if (err < 0) { + doutc(cl, "%llx.%llx failed to allocate pages, %d\n", + ceph_vinop(inode), err); + goto out; + } + + /* should always give us a page-aligned read */ + WARN_ON_ONCE(page_off); + len = err; + err = 0; + + osd_req_op_extent_osd_data_pages(req, 0, pages, len, 0, false, + false); + +The reason of the issue is that subreq->io_iter.count keeps unaligned +value of length: + +[ 347.751182] lib/iov_iter.c:1185 __iov_iter_get_pages_alloc(): maxsize 36864, maxpages 4294967295, start 18446659367320516064 +[ 347.752808] lib/iov_iter.c:1196 __iov_iter_get_pages_alloc(): maxsize 33792, maxpages 4294967295, start 18446659367320516064 +[ 347.754394] lib/iov_iter.c:1015 iter_folioq_get_pages(): maxsize 33792, maxpages 4294967295, extracted 0, _start_offset 18446659367320516064 + +This patch simply assigns the aligned value to subreq->io_iter.count +before calling iov_iter_get_pages_alloc2(). + +[ idryomov: tag the comment with FIXME to make it clear that it's only + a workaround for netfslib not coexisting with fscrypt nicely + (this is also noted in another pre-existing comment) ] + +Cc: David Howells +Cc: stable@vger.kernel.org +Fixes: ee4cdf7ba857 ("netfs: Speed up buffered reading") +Signed-off-by: Viacheslav Dubeyko +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/addr.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/fs/ceph/addr.c ++++ b/fs/ceph/addr.c +@@ -396,6 +396,15 @@ static void ceph_netfs_issue_read(struct + struct page **pages; + size_t page_off; + ++ /* ++ * FIXME: io_iter.count needs to be corrected to aligned ++ * length. Otherwise, iov_iter_get_pages_alloc2() operates ++ * with the initial unaligned length value. As a result, ++ * ceph_msg_data_cursor_init() triggers BUG_ON() in the case ++ * if msg->sparse_read_total > msg->data_length. ++ */ ++ subreq->io_iter.count = len; ++ + err = iov_iter_get_pages_alloc2(&subreq->io_iter, &pages, len, &page_off); + if (err < 0) { + doutc(cl, "%llx.%llx failed to allocate pages, %d\n", diff --git a/queue-6.12/ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch b/queue-6.12/ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch new file mode 100644 index 0000000000..94b9788177 --- /dev/null +++ b/queue-6.12/ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch @@ -0,0 +1,91 @@ +From 72386d5245b249f5a0a8fabb881df7ad947b8ea4 Mon Sep 17 00:00:00 2001 +From: Dennis Marttinen +Date: Thu, 29 May 2025 17:45:12 +0000 +Subject: ceph: set superblock s_magic for IMA fsmagic matching + +From: Dennis Marttinen + +commit 72386d5245b249f5a0a8fabb881df7ad947b8ea4 upstream. + +The CephFS kernel driver forgets to set the filesystem magic signature in +its superblock. As a result, IMA policy rules based on fsmagic matching do +not apply as intended. This causes a major performance regression in Talos +Linux [1] when mounting CephFS volumes, such as when deploying Rook Ceph +[2]. Talos Linux ships a hardened kernel with the following IMA policy +(irrelevant lines omitted): + +[...] +dont_measure fsmagic=0xc36400 # CEPH_SUPER_MAGIC +[...] +measure func=FILE_CHECK mask=^MAY_READ euid=0 +measure func=FILE_CHECK mask=^MAY_READ uid=0 +[...] + +Currently, IMA compares 0xc36400 == 0x0 for CephFS files, resulting in all +files opened with O_RDONLY or O_RDWR getting measured with SHA512 on every +open(2): + +10 69990c87e8af323d47e2d6ae4... ima-ng sha512: /data/cephfs/test-file + +Since O_WRONLY is rare, this results in an order of magnitude lower +performance than expected for practically all file operations. Properly +setting CEPH_SUPER_MAGIC in the CephFS superblock resolves the regression. + +Tests performed on a 3x replicated Ceph v19.3.0 cluster across three +i5-7200U nodes each equipped with one Micron 7400 MAX M.2 disk (BlueStore) +and Gigabit ethernet, on Talos Linux v1.10.2: + +FS-Mark 3.3 +Test: 500 Files, Empty +Files/s > Higher Is Better +6.12.27-talos . 16.6 |==== ++twelho patch . 208.4 |==================================================== + +FS-Mark 3.3 +Test: 500 Files, 1KB Size +Files/s > Higher Is Better +6.12.27-talos . 15.6 |======= ++twelho patch . 118.6 |==================================================== + +FS-Mark 3.3 +Test: 500 Files, 32 Sub Dirs, 1MB Size +Files/s > Higher Is Better +6.12.27-talos . 12.7 |=============== ++twelho patch . 44.7 |===================================================== + +IO500 [3] 2fcd6d6 results (benchmarks within variance omitted): + +| IO500 benchmark | 6.12.27-talos | +twelho patch | Speedup | +|-------------------|----------------|----------------|-----------| +| mdtest-easy-write | 0.018524 kIOPS | 1.135027 kIOPS | 6027.33 % | +| mdtest-hard-write | 0.018498 kIOPS | 0.973312 kIOPS | 5161.71 % | +| ior-easy-read | 0.064727 GiB/s | 0.155324 GiB/s | 139.97 % | +| mdtest-hard-read | 0.018246 kIOPS | 0.780800 kIOPS | 4179.29 % | + +This applies outside of synthetic benchmarks as well, for example, the time +to rsync a 55 MiB directory with ~12k of mostly small files drops from an +unusable 10m5s to a reasonable 26s (23x the throughput). + +[1]: https://www.talos.dev/ +[2]: https://www.talos.dev/v1.10/kubernetes-guides/configuration/ceph-with-rook/ +[3]: https://github.com/IO500/io500 + +Cc: stable@vger.kernel.org +Signed-off-by: Dennis Marttinen +Reviewed-by: Viacheslav Dubeyko +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + fs/ceph/super.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ceph/super.c ++++ b/fs/ceph/super.c +@@ -1227,6 +1227,7 @@ static int ceph_set_super(struct super_b + s->s_time_min = 0; + s->s_time_max = U32_MAX; + s->s_flags |= SB_NODIRATIME | SB_NOATIME; ++ s->s_magic = CEPH_SUPER_MAGIC; + + ceph_fscrypt_set_ops(s); + diff --git a/queue-6.12/cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch b/queue-6.12/cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch new file mode 100644 index 0000000000..df64dd01db --- /dev/null +++ b/queue-6.12/cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch @@ -0,0 +1,64 @@ +From 37fb58a7273726e59f9429c89ade5116083a213d Mon Sep 17 00:00:00 2001 +From: Chen Ridong +Date: Wed, 18 Jun 2025 07:32:17 +0000 +Subject: cgroup,freezer: fix incomplete freezing when attaching tasks +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Chen Ridong + +commit 37fb58a7273726e59f9429c89ade5116083a213d upstream. + +An issue was found: + + # cd /sys/fs/cgroup/freezer/ + # mkdir test + # echo FROZEN > test/freezer.state + # cat test/freezer.state + FROZEN + # sleep 1000 & + [1] 863 + # echo 863 > test/cgroup.procs + # cat test/freezer.state + FREEZING + +When tasks are migrated to a frozen cgroup, the freezer fails to +immediately freeze the tasks, causing the cgroup to remain in the +"FREEZING". + +The freeze_task() function is called before clearing the CGROUP_FROZEN +flag. This causes the freezing() check to incorrectly return false, +preventing __freeze_task() from being invoked for the migrated task. + +To fix this issue, clear the CGROUP_FROZEN state before calling +freeze_task(). + +Fixes: f5d39b020809 ("freezer,sched: Rewrite core freezer logic") +Cc: stable@vger.kernel.org # v6.1+ +Reported-by: Zhong Jiawei +Signed-off-by: Chen Ridong +Acked-by: Michal Koutný +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cgroup/legacy_freezer.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/cgroup/legacy_freezer.c ++++ b/kernel/cgroup/legacy_freezer.c +@@ -188,13 +188,12 @@ static void freezer_attach(struct cgroup + if (!(freezer->state & CGROUP_FREEZING)) { + __thaw_task(task); + } else { +- freeze_task(task); +- + /* clear FROZEN and propagate upwards */ + while (freezer && (freezer->state & CGROUP_FROZEN)) { + freezer->state &= ~CGROUP_FROZEN; + freezer = parent_freezer(freezer); + } ++ freeze_task(task); + } + } + diff --git a/queue-6.12/series b/queue-6.12/series index 89c9247151..4b4ae95402 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -69,3 +69,23 @@ media-imx-jpeg-cleanup-after-an-allocation-error.patch media-uvcvideo-return-the-number-of-processed-controls.patch media-uvcvideo-send-control-events-for-partial-succeeds.patch media-uvcvideo-fix-deferred-probing-error.patch +arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch +arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch +arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch +asoc-codecs-wcd9375-fix-double-free-of-regulator-supplies.patch +asoc-codecs-wcd937x-drop-unused-buck_supply.patch +block-use-plug-request-list-tail-for-one-shot-backmerge-attempt.patch +block-clear-bio_emulates_zone_append-flag-on-bio-completion.patch +bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch +bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch +can-kvaser_pciefd-refine-error-prone-echo_skb_max-handling-logic.patch +can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch +ceph-avoid-kernel-bug-for-encrypted-inode-with-unaligned-file-size.patch +ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch +cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch +bus-firewall-fix-missing-static-inline-annotations-for-stubs.patch +ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch +ata-ahci-disallow-lpm-for-asuspro-d840sa-motherboard.patch +ata-ahci-disallow-lpm-for-asus-b550-f-motherboard.patch +bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch +bus-fsl-mc-fix-get-set_taildrop-command-ids.patch