From: Greg Kroah-Hartman Date: Fri, 20 Jun 2025 08:21:39 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v5.4.295~163 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d88a7b418662f66a4a32ede0cf6e35370738736f;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-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 ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.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-tcan4x5x-fix-power-regulator-retrieval-during-probe.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.6/arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch b/queue-6.6/arm-9447-1-arm-memremap-fix-arch_memremap_can_ram_remap.patch new file mode 100644 index 0000000000..bfb461d257 --- /dev/null +++ b/queue-6.6/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.6/arm-omap-pmic-cpcap-do-not-mess-around-without-cpcap-or-omap4.patch b/queue-6.6/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.6/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.6/arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch b/queue-6.6/arm64-mm-close-theoretical-race-where-stale-tlb-entry-remains-valid.patch new file mode 100644 index 0000000000..cfc4fa7827 --- /dev/null +++ b/queue-6.6/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 +@@ -311,13 +311,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.6/ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch b/queue-6.6/ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.patch new file mode 100644 index 0000000000..91561e3a32 --- /dev/null +++ b/queue-6.6/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.6/bus-fsl-mc-do-not-add-a-device-link-for-the-uapi-used-dpmcp-device.patch b/queue-6.6/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.6/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.6/bus-fsl-mc-fix-get-set_taildrop-command-ids.patch b/queue-6.6/bus-fsl-mc-fix-get-set_taildrop-command-ids.patch new file mode 100644 index 0000000000..8062501fce --- /dev/null +++ b/queue-6.6/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.6/bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch b/queue-6.6/bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch new file mode 100644 index 0000000000..d6ce072dac --- /dev/null +++ b/queue-6.6/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.6/bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch b/queue-6.6/bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch new file mode 100644 index 0000000000..0a081726fa --- /dev/null +++ b/queue-6.6/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 +@@ -586,6 +586,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", +@@ -614,8 +615,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.6/can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch b/queue-6.6/can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch new file mode 100644 index 0000000000..d28617ccaa --- /dev/null +++ b/queue-6.6/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.6/ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch b/queue-6.6/ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch new file mode 100644 index 0000000000..a0f926b64c --- /dev/null +++ b/queue-6.6/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 +@@ -1220,6 +1220,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.6/cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch b/queue-6.6/cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch new file mode 100644 index 0000000000..96b9430a2f --- /dev/null +++ b/queue-6.6/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 +@@ -189,13 +189,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.6/series b/queue-6.6/series index c6445bbe68..7883cce052 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -46,3 +46,14 @@ 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 +bus-mhi-ep-update-read-pointer-only-after-buffer-is-written.patch +bus-mhi-host-fix-conflict-between-power_up-and-syserr.patch +can-tcan4x5x-fix-power-regulator-retrieval-during-probe.patch +ceph-set-superblock-s_magic-for-ima-fsmagic-matching.patch +cgroup-freezer-fix-incomplete-freezing-when-attaching-tasks.patch +ata-pata_via-force-pio-for-atapi-devices-on-vt6415-vt6330.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