- Linux-stable-mirror - lists.linaro.org

Wireless speed regression issue with >6.12.12/6.13.x + firmware update for mediatek MT7925

by Jean-François INGELAERE

Hello guys, I'm reporting an issue with Linux kernel >6.12.12 and 6.13.x with mediatek 7925 serie Wi-Fi card. Reproducible ALWAYS. I got a regression with newer firmware and kernel >6.12.12. The regression seems to be between 6.12.12 and 6.12.13 (and ported to 6.13.x). I'm having low speed connection and especially really bad Upload speed (<4Mbit/s) while running in 802.11ax (better speed in 802.11ac), the MIMO/channel width function seems to be linked with this issue. Here are some speed reports & infos : With 6.12.1 + firmware-202412x speed is correct (1Gbps/800Mbps) With 6.12.12 + firmware-202412x speed is correct (1Gbps/800Mbps) With 6.12.12 + firmware-202503x speed is NOT correct but between acceptable and unacceptable (350Mbps/25Mbps) With 6.12.13 + firmware-202412x speed is NOT correct but between acceptable and unacceptable (280Mbps/80Mbps) With 6.12.13 + firmware-202503x speed is unacceptable (280Mbps/3mbps) With 6.12.13 + firmware-202503x BUT with only one Wi-Fi channel (here ch 36) (See at the end of this message) ie 20Mhz channel width, I got better upload speed than in wider channel width (80Mbps/30Mbps). Kernel 6.13 + Linux Firmware 202412 version. [24305.691750] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin [24305.695281] mt7925e 0000:73:00.0: ASIC revision: 79250000 [24305.772614] Loading firmware: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin [24305.772732] mt7925e 0000:73:00.0: HW/SW Version: 0x8a108a10, Build Time: 20241104132949a [24306.121223] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin [24306.121674] mt7925e 0000:73:00.0: WM Firmware Version: ____000000, Build Time: 20241104133053 [24306.207593] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin [24306.804659] mt7925e 0000:73:00.0 wlp115s0: renamed from wlan0 Linux-firmware >=202501, upload speed unacceptable (download quite the same) : [23925.753738] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin [23925.757066] mt7925e 0000:73:00.0: ASIC revision: 79250000 [23925.834400] Loading firmware: mediatek/mt7925/WIFI_MT7925_PATCH_MCU_1_1_hdr.bin [23925.834518] mt7925e 0000:73:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250113153001a [23926.197786] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin [23926.198160] mt7925e 0000:73:00.0: WM Firmware Version: ____000000, Build Time: 20250113153106 [23926.281524] Loading firmware: mediatek/mt7925/WIFI_RAM_CODE_MT7925_1_1.bin lspci -vvvv 73:00.0 Network controller: MEDIATEK Corp. Device 7925 Subsystem: AzureWave Device 6002 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 195 IOMMU group: 25 Region 0: Memory at 82200000 (64-bit, non-prefetchable) [size=2M] Region 2: Memory at 82400000 (64-bit, non-prefetchable) [size=32K] Capabilities: [80] Express (v2) Endpoint, IntMsgNum 0 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 10W TEE-IO- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset- MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <8us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM Disabled; RCB 64 bytes, LnkDisable- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+ 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- AtomicOpsCtl: ReqEn- IDOReq- IDOCompl- LTR+ EmergencyPowerReductionReq- 10BitTagReq- OBFF Disabled, EETLPPrefixBlk- LnkCap2: Supported Link Speeds: 2.5-5GT/s, Crosslink- Retimer- 2Retimers- DRS- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [e0] MSI: Enable+ Count=1/32 Maskable+ 64bit+ Address: 00000000fee54000 Data: 0022 Masking: fffffffe Pending: 00000000 Capabilities: [f8] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Vendor Specific Information: ID=1556 Rev=1 Len=008 <?> Capabilities: [108 v1] Latency Tolerance Reporting Max snoop latency: 3145728ns Max no snoop latency: 3145728ns Capabilities: [110 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=3us PortTPowerOnTime=52us L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2- ASPM_L1.1- T_CommonMode=0us LTR1.2_Threshold=118784ns L1SubCtl2: T_PwrOn=52us Capabilities: [200 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO+ CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UncorrIntErr- BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UncorrIntErr+ BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- UncorrIntErr+ BlockedTLP- AtomicOpBlocked- TLPBlockedErr- PoisonTLPBlocked- DMWrReqBlocked- IDECheck- MisIDETLP- PCRC_CHECK- TLPXlatBlocked- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CorrIntErr- HeaderOF- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ CorrIntErr+ HeaderOF- AERCap: First Error Pointer: 0e, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Kernel driver in use: mt7925e Kernel modules: mt7925e The AP is a Cisco 9120AXI running in 160Mhz channel width @ (52, 56, 60, 64, 36, 40, 44, 48) channels (yes reported in this order, I think it can mind) 52 is the primary one. Also tested this setup with another cheap AP with channel in "correct" order ? It can maybe be a little better but doesn't change a lot of things. The setup is the same as previously where I was able to get 1Gbit/s Upload speed, just kernel & firmware update. Any way to fix it ? Best regards,

3 months, 3 weeks

1
0
0 0

[PATCH] mm: Update mask post pxd_clear_bad()

by Dev Jain

Since pxd_clear_bad() is an operation changing the state of the page tables, we should call arch_sync_kernel_mappings() post this. Fixes: e80d3909be42 ("mm: track page table modifications in __apply_to_page_range()") Cc: <stable(a)vger.kernel.org> Signed-off-by: Dev Jain <dev.jain(a)arm.com> --- mm/memory.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/mm/memory.c b/mm/memory.c index 78c7ee62795e..9a4a8c710be0 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2987,6 +2987,7 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud, if (!create) continue; pmd_clear_bad(pmd); + *mask = PGTBL_PMD_MODIFIED; } err = apply_to_pte_range(mm, pmd, addr, next, fn, data, create, mask); @@ -3023,6 +3024,7 @@ static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d, if (!create) continue; pud_clear_bad(pud); + *mask = PGTBL_PUD_MODIFIED; } err = apply_to_pmd_range(mm, pud, addr, next, fn, data, create, mask); @@ -3059,6 +3061,7 @@ static int apply_to_p4d_range(struct mm_struct *mm, pgd_t *pgd, if (!create) continue; p4d_clear_bad(p4d); + *mask = PGTBL_P4D_MODIFIED; } err = apply_to_pud_range(mm, p4d, addr, next, fn, data, create, mask); @@ -3095,6 +3098,7 @@ static int __apply_to_page_range(struct mm_struct *mm, unsigned long addr, if (!create) continue; pgd_clear_bad(pgd); + mask = PGTBL_PGD_MODIFIED; } err = apply_to_p4d_range(mm, pgd, addr, next, fn, data, create, &mask); -- 2.30.2

3 months, 3 weeks

3
5
0 0

[PATCH v2] remoteproc: Add device awake calls in rproc boot and shutdown path

by Souradeep Chowdhury

Add device awake calls in case of rproc boot and rproc shutdown path. Currently, device awake call is only present in the recovery path of remoteproc. If a user stops and starts rproc by using the sysfs interface, then on pm suspension the firmware loading fails. Keep the device awake in such a case just like it is done for the recovery path. Fixes: a781e5aa59110 ("remoteproc: core: Prevent system suspend during remoteproc recovery") Signed-off-by: Souradeep Chowdhury <quic_schowdhu(a)quicinc.com> Cc: stable(a)vger.kernel.org --- drivers/remoteproc/remoteproc_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index c2cf0d277729..908a7b8f6c7e 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) pr_err("invalid rproc handle\n"); return -EINVAL; } - + + pm_stay_awake(rproc->dev.parent); dev = &rproc->dev; ret = mutex_lock_interruptible(&rproc->lock); @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) atomic_dec(&rproc->power); unlock_mutex: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_boot); @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) struct device *dev = &rproc->dev; int ret = 0; + pm_stay_awake(rproc->dev.parent); ret = mutex_lock_interruptible(&rproc->lock); if (ret) { dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) rproc->table_ptr = NULL; out: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_shutdown); -- 2.34.1

3 months, 3 weeks

2
1
0 0

[PATCH v1] remoteproc: Add device awake calls in rproc boot and shutdown path

by Souradeep Chowdhury

Add device awake calls in case of rproc boot and rproc shutdown path. Currently, device awake call is only present in the recovery path of remoteproc. If a user stops and starts rproc by using the sysfs interface, then on pm suspension the firmware loading fails. Keep the device awake in such a case just like it is done for the recovery path. Signed-off-by: Souradeep Chowdhury <quic_schowdhu(a)quicinc.com> --- drivers/remoteproc/remoteproc_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index c2cf0d277729..908a7b8f6c7e 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) pr_err("invalid rproc handle\n"); return -EINVAL; } - + + pm_stay_awake(rproc->dev.parent); dev = &rproc->dev; ret = mutex_lock_interruptible(&rproc->lock); @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) atomic_dec(&rproc->power); unlock_mutex: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_boot); @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) struct device *dev = &rproc->dev; int ret = 0; + pm_stay_awake(rproc->dev.parent); ret = mutex_lock_interruptible(&rproc->lock); if (ret) { dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) rproc->table_ptr = NULL; out: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_shutdown); -- 2.34.1

3 months, 3 weeks

3
4
0 0

[v2] remoteproc: Add device awake calls in rproc boot and shutdown path

by Souradeep Chowdhury

Add device awake calls in case of rproc boot and rproc shutdown path. Currently, device awake call is only present in the recovery path of remoteproc. If a user stops and starts rproc by using the sysfs interface, then on pm suspension the firmware loading fails. Keep the device awake in such a case just like it is done for the recovery path. Signed-off-by: Souradeep Chowdhury <quic_schowdhu(a)quicinc.com> Cc: stable(a)vger.kernel.org --- drivers/remoteproc/remoteproc_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c index c2cf0d277729..908a7b8f6c7e 100644 --- a/drivers/remoteproc/remoteproc_core.c +++ b/drivers/remoteproc/remoteproc_core.c @@ -1916,7 +1916,8 @@ int rproc_boot(struct rproc *rproc) pr_err("invalid rproc handle\n"); return -EINVAL; } - + + pm_stay_awake(rproc->dev.parent); dev = &rproc->dev; ret = mutex_lock_interruptible(&rproc->lock); @@ -1961,6 +1962,7 @@ int rproc_boot(struct rproc *rproc) atomic_dec(&rproc->power); unlock_mutex: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_boot); @@ -1991,6 +1993,7 @@ int rproc_shutdown(struct rproc *rproc) struct device *dev = &rproc->dev; int ret = 0; + pm_stay_awake(rproc->dev.parent); ret = mutex_lock_interruptible(&rproc->lock); if (ret) { dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret); @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc) rproc->table_ptr = NULL; out: mutex_unlock(&rproc->lock); + pm_relax(rproc->dev.parent); return ret; } EXPORT_SYMBOL(rproc_shutdown); -- 2.34.1

3 months, 3 weeks

2
1
0 0

[merged mm-stable] sparc-mm-avoid-calling-arch_enter-leave_lazy_mmu-in-set_ptes.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: sparc/mm: avoid calling arch_enter/leave_lazy_mmu() in set_ptes has been removed from the -mm tree. Its filename was sparc-mm-avoid-calling-arch_enter-leave_lazy_mmu-in-set_ptes.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: sparc/mm: avoid calling arch_enter/leave_lazy_mmu() in set_ptes Date: Mon, 3 Mar 2025 14:15:38 +0000 With commit 1a10a44dfc1d ("sparc64: implement the new page table range API") set_ptes was added to the sparc architecture. The implementation included calling arch_enter/leave_lazy_mmu() calls. The patch removes the usage of arch_enter/leave_lazy_mmu() since this implies nesting of lazy mmu regions which is not supported. Without this fix, lazy mmu mode is effectively disabled because we exit the mode after the first set_ptes: remap_pte_range() -> arch_enter_lazy_mmu() -> set_ptes() -> arch_enter_lazy_mmu() -> arch_leave_lazy_mmu() -> arch_leave_lazy_mmu() Powerpc suffered the same problem and fixed it in a corresponding way with commit 47b8def9358c ("powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes"). Link: https://lkml.kernel.org/r/20250303141542.3371656-5-ryan.roberts@arm.com Fixes: 1a10a44dfc1d ("sparc64: implement the new page table range API") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Andreas Larsson <andreas(a)gaisler.com> Acked-by: Juergen Gross <jgross(a)suse.com> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juegren Gross <jgross(a)suse.com> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/sparc/include/asm/pgtable_64.h | 2 -- 1 file changed, 2 deletions(-) --- a/arch/sparc/include/asm/pgtable_64.h~sparc-mm-avoid-calling-arch_enter-leave_lazy_mmu-in-set_ptes +++ a/arch/sparc/include/asm/pgtable_64.h @@ -936,7 +936,6 @@ static inline void __set_pte_at(struct m static inline void set_ptes(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte, unsigned int nr) { - arch_enter_lazy_mmu_mode(); for (;;) { __set_pte_at(mm, addr, ptep, pte, 0); if (--nr == 0) @@ -945,7 +944,6 @@ static inline void set_ptes(struct mm_st pte_val(pte) += PAGE_SIZE; addr += PAGE_SIZE; } - arch_leave_lazy_mmu_mode(); } #define set_ptes set_ptes _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-use-ptep_get-instead-of-directly-dereferencing-pte_t.patch

3 months, 3 weeks

1
0
0 0

[merged mm-stable] sparc-mm-disable-preemption-in-lazy-mmu-mode.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: sparc/mm: disable preemption in lazy mmu mode has been removed from the -mm tree. Its filename was sparc-mm-disable-preemption-in-lazy-mmu-mode.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: sparc/mm: disable preemption in lazy mmu mode Date: Mon, 3 Mar 2025 14:15:37 +0000 Since commit 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") it's been possible for arch_[enter|leave]_lazy_mmu_mode() to be called without holding a page table lock (for the kernel mappings case), and therefore it is possible that preemption may occur while in the lazy mmu mode. The Sparc lazy mmu implementation is not robust to preemption since it stores the lazy mode state in a per-cpu structure and does not attempt to manage that state on task switch. Powerpc had the same issue and fixed it by explicitly disabling preemption in arch_enter_lazy_mmu_mode() and re-enabling in arch_leave_lazy_mmu_mode(). See commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu mode"). Given Sparc's lazy mmu mode is based on powerpc's, let's fix it in the same way here. Link: https://lkml.kernel.org/r/20250303141542.3371656-4-ryan.roberts@arm.com Fixes: 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Andreas Larsson <andreas(a)gaisler.com> Acked-by: Juergen Gross <jgross(a)suse.com> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juegren Gross <jgross(a)suse.com> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/sparc/mm/tlb.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/sparc/mm/tlb.c~sparc-mm-disable-preemption-in-lazy-mmu-mode +++ a/arch/sparc/mm/tlb.c @@ -52,8 +52,10 @@ out: void arch_enter_lazy_mmu_mode(void) { - struct tlb_batch *tb = this_cpu_ptr(&tlb_batch); + struct tlb_batch *tb; + preempt_disable(); + tb = this_cpu_ptr(&tlb_batch); tb->active = 1; } @@ -64,6 +66,7 @@ void arch_leave_lazy_mmu_mode(void) if (tb->tlb_nr) flush_tlb_pending(); tb->active = 0; + preempt_enable(); } static void tlb_batch_add_one(struct mm_struct *mm, unsigned long vaddr, _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-use-ptep_get-instead-of-directly-dereferencing-pte_t.patch

3 months, 3 weeks

1
0
0 0

[merged mm-stable] mm-fix-lazy-mmu-docs-and-usage.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: fix lazy mmu docs and usage has been removed from the -mm tree. Its filename was mm-fix-lazy-mmu-docs-and-usage.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Ryan Roberts <ryan.roberts(a)arm.com> Subject: mm: fix lazy mmu docs and usage Date: Mon, 3 Mar 2025 14:15:35 +0000 Patch series "Fix lazy mmu mode", v2. I'm planning to implement lazy mmu mode for arm64 to optimize vmalloc. As part of that, I will extend lazy mmu mode to cover kernel mappings in vmalloc table walkers. While lazy mmu mode is already used for kernel mappings in a few places, this will extend it's use significantly. Having reviewed the existing lazy mmu implementations in powerpc, sparc and x86, it looks like there are a bunch of bugs, some of which may be more likely to trigger once I extend the use of lazy mmu. So this series attempts to clarify the requirements and fix all the bugs in advance of that series. See patch #1 commit log for all the details. This patch (of 5): The docs, implementations and use of arch_[enter|leave]_lazy_mmu_mode() is a bit of a mess (to put it politely). There are a number of issues related to nesting of lazy mmu regions and confusion over whether the task, when in a lazy mmu region, is preemptible or not. Fix all the issues relating to the core-mm. Follow up commits will fix the arch-specific implementations. 3 arches implement lazy mmu; powerpc, sparc and x86. When arch_[enter|leave]_lazy_mmu_mode() was first introduced by commit 6606c3e0da53 ("[PATCH] paravirt: lazy mmu mode hooks.patch"), it was expected that lazy mmu regions would never nest and that the appropriate page table lock(s) would be held while in the region, thus ensuring the region is non-preemptible. Additionally lazy mmu regions were only used during manipulation of user mappings. Commit 38e0edb15bd0 ("mm/apply_to_range: call pte function with lazy updates") started invoking the lazy mmu mode in apply_to_pte_range(), which is used for both user and kernel mappings. For kernel mappings the region is no longer protected by any lock so there is no longer any guarantee about non-preemptibility. Additionally, for RT configs, the holding the PTL only implies no CPU migration, it doesn't prevent preemption. Commit bcc6cc832573 ("mm: add default definition of set_ptes()") added arch_[enter|leave]_lazy_mmu_mode() to the default implementation of set_ptes(), used by x86. So after this commit, lazy mmu regions can be nested. Additionally commit 1a10a44dfc1d ("sparc64: implement the new page table range API") and commit 9fee28baa601 ("powerpc: implement the new page table range API") did the same for the sparc and powerpc set_ptes() overrides. powerpc couldn't deal with preemption so avoids it in commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu mode"), which explicitly disables preemption for the whole region in its implementation. x86 can support preemption (or at least it could until it tried to add support nesting; more on this below). Sparc looks to be totally broken in the face of preemption, as far as I can tell. powerpc can't deal with nesting, so avoids it in commit 47b8def9358c ("powerpc/mm: Avoid calling arch_enter/leave_lazy_mmu() in set_ptes"), which removes the lazy mmu calls from its implementation of set_ptes(). x86 attempted to support nesting in commit 49147beb0ccb ("x86/xen: allow nesting of same lazy mode") but as far as I can tell, this breaks its support for preemption. In short, it's all a mess; the semantics for arch_[enter|leave]_lazy_mmu_mode() are not clearly defined and as a result the implementations all have different expectations, sticking plasters and bugs. arm64 is aiming to start using these hooks, so let's clean everything up before adding an arm64 implementation. Update the documentation to state that lazy mmu regions can never be nested, must not be called in interrupt context and preemption may or may not be enabled for the duration of the region. And fix the generic implementation of set_ptes() to avoid nesting. arch-specific fixes to conform to the new spec will proceed this one. These issues were spotted by code review and I have no evidence of issues being reported in the wild. Link: https://lkml.kernel.org/r/20250303141542.3371656-1-ryan.roberts@arm.com Link: https://lkml.kernel.org/r/20250303141542.3371656-2-ryan.roberts@arm.com Fixes: bcc6cc832573 ("mm: add default definition of set_ptes()") Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: Juergen Gross <jgross(a)suse.com> Cc: Andreas Larsson <andreas(a)gaisler.com> Cc: Borislav Betkov <bp(a)alien8.de> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David S. Miller <davem(a)davemloft.net> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Juegren Gross <jgross(a)suse.com> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Thomas Gleinxer <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/pgtable.h | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/include/linux/pgtable.h~mm-fix-lazy-mmu-docs-and-usage +++ a/include/linux/pgtable.h @@ -222,10 +222,14 @@ static inline int pmd_dirty(pmd_t pmd) * hazard could result in the direct mode hypervisor case, since the actual * write to the page tables may not yet have taken place, so reads though * a raw PTE pointer after it has been modified are not guaranteed to be - * up to date. This mode can only be entered and left under the protection of - * the page table locks for all page tables which may be modified. In the UP - * case, this is required so that preemption is disabled, and in the SMP case, - * it must synchronize the delayed page table writes properly on other CPUs. + * up to date. + * + * In the general case, no lock is guaranteed to be held between entry and exit + * of the lazy mode. So the implementation must assume preemption may be enabled + * and cpu migration is possible; it must take steps to be robust against this. + * (In practice, for user PTE updates, the appropriate page table lock(s) are + * held, but for kernel PTE updates, no lock is held). Nesting is not permitted + * and the mode cannot be used in interrupt context. */ #ifndef __HAVE_ARCH_ENTER_LAZY_MMU_MODE #define arch_enter_lazy_mmu_mode() do {} while (0) @@ -287,7 +291,6 @@ static inline void set_ptes(struct mm_st { page_table_check_ptes_set(mm, ptep, pte, nr); - arch_enter_lazy_mmu_mode(); for (;;) { set_pte(ptep, pte); if (--nr == 0) @@ -295,7 +298,6 @@ static inline void set_ptes(struct mm_st ptep++; pte = pte_next_pfn(pte); } - arch_leave_lazy_mmu_mode(); } #endif #define set_pte_at(mm, addr, ptep, pte) set_ptes(mm, addr, ptep, pte, 1) _ Patches currently in -mm which might be from ryan.roberts(a)arm.com are mm-use-ptep_get-instead-of-directly-dereferencing-pte_t.patch

3 months, 3 weeks

1
0
0 0

[merged mm-stable] mm-make-page_mapped_in_vma-hugetlb-walk-aware.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm: make page_mapped_in_vma() hugetlb walk aware has been removed from the -mm tree. Its filename was mm-make-page_mapped_in_vma-hugetlb-walk-aware.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jane Chu <jane.chu(a)oracle.com> Subject: mm: make page_mapped_in_vma() hugetlb walk aware Date: Mon, 24 Feb 2025 14:14:45 -0700 When a process consumes a UE in a page, the memory failure handler attempts to collect information for a potential SIGBUS. If the page is an anonymous page, page_mapped_in_vma(page, vma) is invoked in order to 1. retrieve the vaddr from the process' address space, 2. verify that the vaddr is indeed mapped to the poisoned page, where 'page' is the precise small page with UE. It's been observed that when injecting poison to a non-head subpage of an anonymous hugetlb page, no SIGBUS shows up, while injecting to the head page produces a SIGBUS. The cause is that, though hugetlb_walk() returns a valid pmd entry (on x86), but check_pte() detects mismatch between the head page per the pmd and the input subpage. Thus the vaddr is considered not mapped to the subpage and the process is not collected for SIGBUS purpose. This is the calling stack: collect_procs_anon page_mapped_in_vma page_vma_mapped_walk hugetlb_walk huge_pte_lock check_pte check_pte() header says that it "check if [pvmw->pfn, @pvmw->pfn + @pvmw->nr_pages) is mapped at the @pvmw->pte" but practically works only if pvmw->pfn is the head page pfn at pvmw->pte. Hindsight acknowledging that some pvmw->pte could point to a hugepage of some sort such that it makes sense to make check_pte() work for hugepage. Link: https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kirill A. Shuemov <kirill.shutemov(a)linux.intel.com> Cc: linmiaohe <linmiaohe(a)huawei.com> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Peter Xu <peterx(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_vma_mapped.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/mm/page_vma_mapped.c~mm-make-page_mapped_in_vma-hugetlb-walk-aware +++ a/mm/page_vma_mapped.c @@ -84,6 +84,7 @@ again: * mapped at the @pvmw->pte * @pvmw: page_vma_mapped_walk struct, includes a pair pte and pfn range * for checking + * @pte_nr: the number of small pages described by @pvmw->pte. * * page_vma_mapped_walk() found a place where pfn range is *potentially* * mapped. check_pte() has to validate this. @@ -100,7 +101,7 @@ again: * Otherwise, return false. * */ -static bool check_pte(struct page_vma_mapped_walk *pvmw) +static bool check_pte(struct page_vma_mapped_walk *pvmw, unsigned long pte_nr) { unsigned long pfn; pte_t ptent = ptep_get(pvmw->pte); @@ -132,7 +133,11 @@ static bool check_pte(struct page_vma_ma pfn = pte_pfn(ptent); } - return (pfn - pvmw->pfn) < pvmw->nr_pages; + if ((pfn + pte_nr - 1) < pvmw->pfn) + return false; + if (pfn > (pvmw->pfn + pvmw->nr_pages - 1)) + return false; + return true; } /* Returns true if the two ranges overlap. Careful to not overflow. */ @@ -207,7 +212,7 @@ bool page_vma_mapped_walk(struct page_vm return false; pvmw->ptl = huge_pte_lock(hstate, mm, pvmw->pte); - if (!check_pte(pvmw)) + if (!check_pte(pvmw, pages_per_huge_page(hstate))) return not_found(pvmw); return true; } @@ -290,7 +295,7 @@ restart: goto next_pte; } this_pte: - if (check_pte(pvmw)) + if (check_pte(pvmw, 1)) return true; next_pte: do { _ Patches currently in -mm which might be from jane.chu(a)oracle.com are

3 months, 3 weeks

1
0
0 0

[merged mm-stable] mm-damon-avoid-applying-damos-action-to-same-entity-multiple-times.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon: avoid applying DAMOS action to same entity multiple times has been removed from the -mm tree. Its filename was mm-damon-avoid-applying-damos-action-to-same-entity-multiple-times.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon: avoid applying DAMOS action to same entity multiple times Date: Fri, 7 Feb 2025 13:20:33 -0800 'paddr' DAMON operations set can apply a DAMOS scheme's action to a large folio multiple times in single DAMOS-regions-walk if the folio is laid on multiple DAMON regions. Add a field for DAMOS scheme object that can be used by the underlying ops to know what was the last entity that the scheme's action has applied. The core layer unsets the field when each DAMOS-regions-walk is done for the given scheme. And update 'paddr' ops to use the infrastructure to avoid the problem. Link: https://lkml.kernel.org/r/20250207212033.45269-3-sj@kernel.org Fixes: 57223ac29584 ("mm/damon/paddr: support the pageout scheme") Signed-off-by: SeongJae Park <sj(a)kernel.org> Reported-by: Usama Arif <usamaarif642(a)gmail.com> Closes: https://lore.kernel.org/20250203225604.44742-3-usamaarif642@gmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/damon.h | 11 +++++++++++ mm/damon/core.c | 1 + mm/damon/paddr.c | 39 +++++++++++++++++++++++++++------------ 3 files changed, 39 insertions(+), 12 deletions(-) --- a/include/linux/damon.h~mm-damon-avoid-applying-damos-action-to-same-entity-multiple-times +++ a/include/linux/damon.h @@ -432,6 +432,7 @@ struct damos_access_pattern { * @wmarks: Watermarks for automated (in)activation of this scheme. * @target_nid: Destination node if @action is "migrate_{hot,cold}". * @filters: Additional set of &struct damos_filter for &action. + * @last_applied: Last @action applied ops-managing entity. * @stat: Statistics of this scheme. * @list: List head for siblings. * @@ -454,6 +455,15 @@ struct damos_access_pattern { * implementation could check pages of the region and skip &action to respect * &filters * + * The minimum entity that @action can be applied depends on the underlying + * &struct damon_operations. Since it may not be aligned with the core layer + * abstract, namely &struct damon_region, &struct damon_operations could apply + * @action to same entity multiple times. Large folios that underlying on + * multiple &struct damon region objects could be such examples. The &struct + * damon_operations can use @last_applied to avoid that. DAMOS core logic + * unsets @last_applied when each regions walking for applying the scheme is + * finished. + * * After applying the &action to each region, &stat_count and &stat_sz is * updated to reflect the number of regions and total size of regions that the * &action is applied. @@ -482,6 +492,7 @@ struct damos { int target_nid; }; struct list_head filters; + void *last_applied; struct damos_stat stat; struct list_head list; }; --- a/mm/damon/core.c~mm-damon-avoid-applying-damos-action-to-same-entity-multiple-times +++ a/mm/damon/core.c @@ -1856,6 +1856,7 @@ static void kdamond_apply_schemes(struct s->next_apply_sis = c->passed_sample_intervals + (s->apply_interval_us ? s->apply_interval_us : c->attrs.aggr_interval) / sample_interval; + s->last_applied = NULL; } } --- a/mm/damon/paddr.c~mm-damon-avoid-applying-damos-action-to-same-entity-multiple-times +++ a/mm/damon/paddr.c @@ -254,6 +254,17 @@ static bool damos_pa_filter_out(struct d return false; } +static bool damon_pa_invalid_damos_folio(struct folio *folio, struct damos *s) +{ + if (!folio) + return true; + if (folio == s->last_applied) { + folio_put(folio); + return true; + } + return false; +} + static unsigned long damon_pa_pageout(struct damon_region *r, struct damos *s, unsigned long *sz_filter_passed) { @@ -261,6 +272,7 @@ static unsigned long damon_pa_pageout(st LIST_HEAD(folio_list); bool install_young_filter = true; struct damos_filter *filter; + struct folio *folio; /* check access in page level again by default */ damos_for_each_filter(filter, s) { @@ -279,9 +291,8 @@ static unsigned long damon_pa_pageout(st addr = r->ar.start; while (addr < r->ar.end) { - struct folio *folio = damon_get_folio(PHYS_PFN(addr)); - - if (!folio) { + folio = damon_get_folio(PHYS_PFN(addr)); + if (damon_pa_invalid_damos_folio(folio, s)) { addr += PAGE_SIZE; continue; } @@ -307,6 +318,7 @@ put_folio: damos_destroy_filter(filter); applied = reclaim_pages(&folio_list); cond_resched(); + s->last_applied = folio; return applied * PAGE_SIZE; } @@ -315,12 +327,12 @@ static inline unsigned long damon_pa_mar unsigned long *sz_filter_passed) { unsigned long addr, applied = 0; + struct folio *folio; addr = r->ar.start; while (addr < r->ar.end) { - struct folio *folio = damon_get_folio(PHYS_PFN(addr)); - - if (!folio) { + folio = damon_get_folio(PHYS_PFN(addr)); + if (damon_pa_invalid_damos_folio(folio, s)) { addr += PAGE_SIZE; continue; } @@ -339,6 +351,7 @@ put_folio: addr += folio_size(folio); folio_put(folio); } + s->last_applied = folio; return applied * PAGE_SIZE; } @@ -482,12 +495,12 @@ static unsigned long damon_pa_migrate(st { unsigned long addr, applied; LIST_HEAD(folio_list); + struct folio *folio; addr = r->ar.start; while (addr < r->ar.end) { - struct folio *folio = damon_get_folio(PHYS_PFN(addr)); - - if (!folio) { + folio = damon_get_folio(PHYS_PFN(addr)); + if (damon_pa_invalid_damos_folio(folio, s)) { addr += PAGE_SIZE; continue; } @@ -506,6 +519,7 @@ put_folio: } applied = damon_pa_migrate_pages(&folio_list, s->target_nid); cond_resched(); + s->last_applied = folio; return applied * PAGE_SIZE; } @@ -523,15 +537,15 @@ static unsigned long damon_pa_stat(struc { unsigned long addr; LIST_HEAD(folio_list); + struct folio *folio; if (!damon_pa_scheme_has_filter(s)) return 0; addr = r->ar.start; while (addr < r->ar.end) { - struct folio *folio = damon_get_folio(PHYS_PFN(addr)); - - if (!folio) { + folio = damon_get_folio(PHYS_PFN(addr)); + if (damon_pa_invalid_damos_folio(folio, s)) { addr += PAGE_SIZE; continue; } @@ -541,6 +555,7 @@ static unsigned long damon_pa_stat(struc addr += folio_size(folio); folio_put(folio); } + s->last_applied = folio; return 0; } _ Patches currently in -mm which might be from sj(a)kernel.org are mm-damon-sysfs-schemes-let-damon_sysfs_scheme_set_filters-be-used-for-different-named-directories.patch mm-damon-sysfs-schemes-implement-core_filters-and-ops_filters-directories.patch mm-damon-sysfs-schemes-commit-filters-in-coreops_filters-directories.patch mm-damon-core-expose-damos_filter_for_ops-to-damon-kernel-api-callers.patch mm-damon-sysfs-schemes-record-filters-of-which-layer-should-be-added-to-the-given-filters-directory.patch mm-damon-sysfs-schemes-return-error-when-for-attempts-to-install-filters-on-wrong-sysfs-directory.patch docs-abi-damon-document-coreops_filters-directories.patch docs-admin-guide-mm-damon-usage-update-for-coreops_filters-directories.patch mm-damon-sysfs-validate-user-inputs-from-damon_sysfs_commit_input.patch mm-damon-core-invoke-kdamond_call-after-merging-is-done-if-possible.patch mm-damon-core-make-damon_set_attrs-be-safe-to-be-called-from-damon_call.patch mm-damon-sysfs-handle-commit-command-using-damon_call.patch mm-damon-sysfs-remove-damon_sysfs_cmd_request-code-from-damon_sysfs_handle_cmd.patch mm-damon-sysfs-remove-damon_sysfs_cmd_request_callback-and-its-callers.patch mm-damon-sysfs-remove-damon_sysfs_cmd_request-and-its-readers.patch mm-damon-sysfs-schemes-remove-obsolete-comment-for-damon_sysfs_schemes_clear_regions.patch mm-damon-remove-damon_callback-private.patch mm-damon-remove-before_start-of-damon_callback.patch mm-damon-remove-damon_callback-after_sampling.patch mm-damon-remove-damon_callback-before_damos_apply.patch mm-damon-remove-damon_operations-reset_aggregated.patch mm-damon-sysfs-schemes-avoid-wformat-security-warning-on-damon_sysfs_access_pattern_add_range_dir.patch mm-madvise-use-is_memory_failure-from-madvise_do_behavior.patch mm-madvise-split-out-populate-behavior-check-logic.patch mm-madvise-deduplicate-madvise_do_behavior-skip-case-handlings.patch mm-madvise-remove-len-parameter-of-madvise_do_behavior.patch

3 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror