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

[PATCH] clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src

by Heiko Stuebner

dclk_vop2_src currently has CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT flags set, which is vastly different than dclk_vop0_src or dclk_vop1_src, which have none of those. With these flags in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop these flags from dclk_vop2_src and make the flags the same as on dclk_vop0 and dclk_vop1. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable(a)vger.kernel.org Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/clk/rockchip/clk-rk3588.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c index 1694223f4f84..cf83242d1726 100644 --- a/drivers/clk/rockchip/clk-rk3588.c +++ b/drivers/clk/rockchip/clk-rk3588.c @@ -2094,7 +2094,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = { COMPOSITE(DCLK_VOP1_SRC, "dclk_vop1_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(111), 14, 2, MFLAGS, 9, 5, DFLAGS, RK3588_CLKGATE_CON(52), 11, GFLAGS), - COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, + COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(112), 5, 2, MFLAGS, 0, 5, DFLAGS, RK3588_CLKGATE_CON(52), 12, GFLAGS), COMPOSITE_NODIV(DCLK_VOP0, "dclk_vop0", dclk_vop0_p, -- 2.47.2

6 days, 12 hours

5
8
0 0

[PATCH net 1/1] batman-adv: Release references to inactive interfaces

by Simon Wunderlich

From: Sven Eckelmann <sven(a)narfation.org> Trying to dump the originators or the neighbors via netlink for a meshif with an inactive primary interface is not allowed. The dump functions were checking this correctly but they didn't handle non-existing primary interfaces and existing _inactive_ interfaces differently. (Primary) batadv_hard_ifaces hold a references to a net_device. And accessing them is only allowed when either being in a RCU/spinlock protected section or when holding a valid reference to them. The netlink dump functions use the latter. But because the missing specific error handling for inactive primary interfaces, the reference was never dropped. This reference counting error was only detected when the interface should have been removed from the system: unregister_netdevice: waiting for batadv_slave_0 to become free. Usage count = 2 Cc: stable(a)vger.kernel.org Fixes: 6ecc4fd6c2f4 ("batman-adv: netlink: reduce duplicate code by returning interfaces") Reported-by: syzbot+881d65229ca4f9ae8c84(a)syzkaller.appspotmail.com Reported-by: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> --- net/batman-adv/originator.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index a464ff96b9291..ed89d7fd1e7f4 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -764,11 +764,16 @@ int batadv_hardif_neigh_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); @@ -1333,11 +1338,16 @@ int batadv_orig_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); -- 2.47.3

6 days, 12 hours

2
1
0 0

[PATCH] riscv: Fix memory leak in module_frob_arch_sections()

by Miaoqian Lin

The current code directly overwrites the scratch pointer with the return value of kvrealloc(). If kvrealloc() fails and returns NULL, the original buffer becomes unreachable, causing a memory leak. Fix this by using a temporary variable to store kvrealloc()'s return value and only update the scratch pointer on success. Found via static anlaysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: be17c0df6795 ("riscv: module: Optimize PLT/GOT entry counting") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/riscv/kernel/module-sections.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/module-sections.c b/arch/riscv/kernel/module-sections.c index 75551ac6504c..1675cbad8619 100644 --- a/arch/riscv/kernel/module-sections.c +++ b/arch/riscv/kernel/module-sections.c @@ -119,6 +119,7 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, unsigned int num_plts = 0; unsigned int num_gots = 0; Elf_Rela *scratch = NULL; + Elf_Rela *new_scratch; size_t scratch_size = 0; int i; @@ -168,9 +169,12 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, scratch_size_needed = (num_scratch_relas + num_relas) * sizeof(*scratch); if (scratch_size_needed > scratch_size) { scratch_size = scratch_size_needed; - scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); - if (!scratch) + new_scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); + if (!new_scratch) { + kvfree(scratch); return -ENOMEM; + } + scratch = new_scratch; } for (size_t j = 0; j < num_relas; j++) -- 2.39.5 (Apple Git-154)

6 days, 12 hours

2
1
0 0

[PATCH AUTOSEL 6.17-6.1] smb/server: fix possible memory leak in smb2_read()

by Sasha Levin

From: ZhangGuoDong <zhangguodong(a)kylinos.cn> [ Upstream commit 6fced056d2cc8d01b326e6fcfabaacb9850b71a4 ] Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree(). Co-developed-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ZhangGuoDong <zhangguodong(a)kylinos.cn> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## **Backport Status: YES** ### **Extensive Analysis** Based on comprehensive semantic code analysis and repository examination, this commit **should be backported** to stable kernel trees. --- ## **1. Code Change Analysis** The commit adds a single line to fix a memory leak in `fs/smb/server/smb2pdu.c`: ```c nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); // <-- Added line err = nbytes; goto out; } ``` **What was wrong:** Memory allocated at line 6821 (`aux_payload_buf = kvzalloc(ALIGN(length, 8), KSMBD_DEFAULT_GFP)`) was not freed when `ksmbd_vfs_read()` fails, while all other error paths properly call `kvfree()`. --- ## **2. Semantic Analysis Tools Used** ### **Tool 1: mcp__semcode__find_function** - Located `smb2_read()` in `fs/smb/server/smb2pdu.c:6727-6895` - Confirmed it's an SMB2 protocol handler (169 lines, 24 function calls) - Return type: `int` (returns error codes) ### **Tool 2: mcp__semcode__find_callers** - Result: No direct function callers - However, cross-referenced with `smb2ops.c:183` showing `smb2_read` is registered as a handler: `[SMB2_READ_HE] = { .proc = smb2_read }` - **Conclusion:** This is a protocol handler invoked by the SMB2 message dispatcher, meaning it's **directly user-triggerable** via network requests ### **Tool 3: mcp__semcode__find_calls** - Analyzed `ksmbd_vfs_read()` dependencies - Found it can fail with multiple error codes: `-EISDIR`, `-EACCES`, `-EAGAIN`, plus any errors from `kernel_read()` - **All of these failure paths trigger the memory leak** ### **Tool 4: git blame & git log** - Bug introduced: commit `e2f34481b24db2` (2021-03-16) - **4 years old!** - Recent modification: commit `06a025448b572c` (2024-11-30) changed allocation to `ALIGN(length, 8)` but didn't fix the leak - Found 15+ similar "memory leak" fixes in ksmbd history, indicating active maintenance --- ## **3. Impact Scope Analysis** ### **User Exposure: CRITICAL** - **Protocol Handler:** Any SMB client can trigger this by sending SMB2 READ requests - **Network-facing:** ksmbd is a kernel SMB server exposed to network clients - **No authentication required to trigger:** The error path can be reached even with permission errors ### **Trigger Conditions (from VFS analysis):** 1. **-EISDIR**: Client tries to read a directory 2. **-EACCES**: Permission denied (no FILE_READ_DATA or FILE_EXECUTE access) 3. **-EAGAIN**: File is locked by another process 4. **kernel_read() failures**: Various VFS/filesystem errors All of these are **easily triggerable** by malicious or misbehaving clients. ### **Memory Leak Severity: HIGH** - **Allocation size:** `ALIGN(length, 8)` where `length` is client- controlled - **Maximum per leak:** Up to `SMB3_MAX_IOSIZE` = **8 MB** (from smb2pdu.h:28) - **Default size:** `SMB21_DEFAULT_IOSIZE` = **1 MB** (from smb2pdu.h:25) - **Attack scenario:** An attacker could repeatedly: 1. Send READ requests for locked files (triggers -EAGAIN) 2. Each failed request leaks up to 8MB 3. 100 requests = 800MB leaked 4. Can exhaust server memory leading to **DoS** --- ## **4. Regression Risk Analysis** ### **Risk Level: VERY LOW** - **Change size:** Single line addition - **Operation:** Adding missing cleanup (defensive programming) - **No behavior change:** Only affects error path that already returns failure - **Idempotent:** `kvfree()` is safe to call and simply frees allocated memory - **No dependencies:** No API changes or external impact --- ## **5. Stable Tree Compliance** | Criterion | Status | Evidence | |-----------|--------|----------| | Fixes important bug | ✅ YES | Memory leak leading to potential DoS | | Small and contained | ✅ YES | 1 line change, single function | | No new features | ✅ YES | Pure bug fix | | No architectural changes | ✅ YES | No structural modifications | | Low regression risk | ✅ YES | Minimal, defensive change | | Confined to subsystem | ✅ YES | Only affects ksmbd | | User-facing impact | ✅ YES | Affects all ksmbd users | --- ## **6. Comparison with Similar Commits** Recent ksmbd fixes in the repository show similar patterns: - `379510a815cb2`: "fix possible refcount leak in smb2_sess_setup()" - `5929e98f3bb76`: "fix potential double free on smb2_read_pipe() error path" - `e523a26c05672`: "fix passing freed memory 'aux_payload_buf'" - `809d50d36e71b`: "fix memory leak in smb2_lock()" **All these are typical stable tree backport candidates** with similar characteristics (small resource leak fixes). --- ## **7. Missing Stable Tags** **Notable:** The commit lacks explicit stable tree tags: - ❌ No `Cc: stable(a)vger.kernel.org` - ❌ No `Fixes:` tag pointing to the original buggy commit However, this doesn't diminish backport worthiness - the technical merits clearly justify backporting. --- ## **Conclusion** This commit is an **excellent candidate for backporting** because: 1. **Security concern:** Remote memory exhaustion DoS vector 2. **Long-standing bug:** Present since ksmbd's introduction (4+ years) 3. **Wide impact:** Affects all ksmbd deployments 4. **Minimal risk:** Single-line defensive fix 5. **Clear bug fix:** Unambiguous resource leak on error path 6. **Pattern consistency:** Matches other successfully backported ksmbd fixes **Recommendation:** Backport to all active stable trees where ksmbd exists (5.15+). fs/smb/server/smb2pdu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 287200d7c0764..409b85af82e1c 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -6826,6 +6826,7 @@ int smb2_read(struct ksmbd_work *work) nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); err = nbytes; goto out; } -- 2.51.0

6 days, 12 hours

1
25
0 0

[PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts

by Ravi Kumar Bandi

The pcie-xilinx-dma-pl driver does not enable INTx interrupts after initializing the port, preventing INTx interrupts from PCIe endpoints from flowing through the Xilinx XDMA root port bridge. This issue affects kernel 6.6.0 and later versions. This patch allows INTx interrupts generated by PCIe endpoints to flow through the root port. Tested the fix on a board with two endpoints generating INTx interrupts. Interrupts are properly detected and serviced. The /proc/interrupts output shows: [...] 32: 320 0 pl_dma:RC-Event 16 Level 400000000.axi-pcie, azdrv 52: 470 0 pl_dma:RC-Event 16 Level 500000000.axi-pcie, azdrv [...] Changes since v1:: - Fixed commit message per reviewer's comments Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ravi Kumar Bandi <ravib(a)amazon.com> --- drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c index b037c8f315e4..cc539292d10a 100644 --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c +++ b/drivers/pci/controller/pcie-xilinx-dma-pl.c @@ -659,6 +659,12 @@ static int xilinx_pl_dma_pcie_setup_irq(struct pl_dma_pcie *port) return err; } + /* Enable interrupts */ + pcie_write(port, XILINX_PCIE_DMA_IMR_ALL_MASK, + XILINX_PCIE_DMA_REG_IMR); + pcie_write(port, XILINX_PCIE_DMA_IDRN_MASK, + XILINX_PCIE_DMA_REG_IDRN_MASK); + return 0; } -- 2.47.3

6 days, 12 hours

8
31
0 0

[PATCH] powerpc: Fix mprotect on book3s32

by Dave Vasilevsky via B4 Relay

From: Dave Vasilevsky <dave(a)vasilevsky.ca> On 32-bit book3s with hash-MMUs, tlb_flush() was a no-op. This was unnoticed because all uses until recently were for unmaps, and thus handled by __tlb_remove_tlb_entry(). After commit 4a18419f71cd ("mm/mprotect: use mmu_gather") in kernel 5.19, tlb_gather_mmu() started being used for mprotect as well. This caused mprotect to simply not work on these machines: int *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); *ptr = 1; // force HPTE to be created mprotect(ptr, 4096, PROT_READ); *ptr = 2; // should segfault, but succeeds Fixed by making tlb_flush() actually flush TLB pages. This finally agrees with the behaviour of boot3s64's tlb_flush(). Fixes: 4a18419f71cd ("mm/mprotect: use mmu_gather") Signed-off-by: Dave Vasilevsky <dave(a)vasilevsky.ca> --- arch/powerpc/include/asm/book3s/32/tlbflush.h | 8 ++++++-- arch/powerpc/mm/book3s32/tlb.c | 6 ++++++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/32/tlbflush.h b/arch/powerpc/include/asm/book3s/32/tlbflush.h index e43534da5207aa3b0cb3c07b78e29b833c141f3f..b8c587ad2ea954f179246a57d6e86e45e91dcfdc 100644 --- a/arch/powerpc/include/asm/book3s/32/tlbflush.h +++ b/arch/powerpc/include/asm/book3s/32/tlbflush.h @@ -11,6 +11,7 @@ void hash__flush_tlb_mm(struct mm_struct *mm); void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr); void hash__flush_range(struct mm_struct *mm, unsigned long start, unsigned long end); +void hash__flush_gather(struct mmu_gather *tlb); #ifdef CONFIG_SMP void _tlbie(unsigned long address); @@ -28,9 +29,12 @@ void _tlbia(void); */ static inline void tlb_flush(struct mmu_gather *tlb) { - /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ - if (!mmu_has_feature(MMU_FTR_HPTE_TABLE)) + if (mmu_has_feature(MMU_FTR_HPTE_TABLE)) { + hash__flush_gather(tlb); + } else { + /* 603 needs to flush the whole TLB here since it doesn't use a hash table. */ _tlbia(); + } } static inline void flush_range(struct mm_struct *mm, unsigned long start, unsigned long end) diff --git a/arch/powerpc/mm/book3s32/tlb.c b/arch/powerpc/mm/book3s32/tlb.c index 9ad6b56bfec96e989b96f027d075ad5812500854..3da95ecfbbb296303082e378425e92a5fbdbfac8 100644 --- a/arch/powerpc/mm/book3s32/tlb.c +++ b/arch/powerpc/mm/book3s32/tlb.c @@ -105,3 +105,9 @@ void hash__flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr) flush_hash_pages(mm->context.id, vmaddr, pmd_val(*pmd), 1); } EXPORT_SYMBOL(hash__flush_tlb_page); + +void hash__flush_gather(struct mmu_gather *tlb) +{ + hash__flush_range(tlb->mm, tlb->start, tlb->end); +} +EXPORT_SYMBOL(hash__flush_gather); --- base-commit: dcb6fa37fd7bc9c3d2b066329b0d27dedf8becaa change-id: 20251027-vasi-mprotect-g3-f8f5278d4140 Best regards, -- Dave Vasilevsky <dave(a)vasilevsky.ca>

6 days, 14 hours

2
1
0 0

[PATCH v3 0/3] Fixes/improvements for SM6350 UFS

by Luca Weiss

Fix the order of the freq-table-hz property, then convert to OPP tables and add interconnect support for UFS for the SM6350 SoC. Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com> --- Changes in v3: - Actually pick up tags, sorry about that - Link to v2: https://lore.kernel.org/r/20251023-sm6350-ufs-things-v2-0-799d59178713@fair… Changes in v2: - Resend, pick up tags - Link to v1: https://lore.kernel.org/r/20250314-sm6350-ufs-things-v1-0-3600362cc52c@fair… --- Luca Weiss (3): arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS arm64: dts: qcom: sm6350: Add OPP table support to UFSHC arm64: dts: qcom: sm6350: Add interconnect support to UFS arch/arm64/boot/dts/qcom/sm6350.dtsi | 49 ++++++++++++++++++++++++++++-------- 1 file changed, 39 insertions(+), 10 deletions(-) --- base-commit: a92c761bcac3d5042559107fa7679470727a4bcb change-id: 20250314-sm6350-ufs-things-53c5de9fec5e Best regards, -- Luca Weiss <luca.weiss(a)fairphone.com>

6 days, 14 hours

2
2
0 0

+ mm-truncate-unmap-large-folio-on-split-failure.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/truncate: unmap large folio on split failure has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-truncate-unmap-large-folio-on-split-failure.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kiryl Shutsemau <kas(a)kernel.org> Subject: mm/truncate: unmap large folio on split failure Date: Mon, 27 Oct 2025 11:56:36 +0000 Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. This behavior might not be respected on truncation. During truncation, the kernel splits a large folio in order to reclaim memory. As a side effect, it unmaps the folio and destroys PMD mappings of the folio. The folio will be refaulted as PTEs and SIGBUS semantics are preserved. However, if the split fails, PMD mappings are preserved and the user will not receive SIGBUS on any accesses within the PMD. Unmap the folio on split failure. It will lead to refault as PTEs and preserve SIGBUS semantics. Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/20251027115636.82382-3-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau <kas(a)kernel.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/truncate.c | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) --- a/mm/truncate.c~mm-truncate-unmap-large-folio-on-split-failure +++ a/mm/truncate.c @@ -177,6 +177,32 @@ int truncate_inode_folio(struct address_ return 0; } +static int try_folio_split_or_unmap(struct folio *folio, struct page *split_at, + unsigned long min_order) +{ + enum ttu_flags ttu_flags = + TTU_SYNC | + TTU_SPLIT_HUGE_PMD | + TTU_IGNORE_MLOCK; + int ret; + + ret = try_folio_split_to_order(folio, split_at, min_order); + + /* + * If the split fails, unmap the folio, so it will be refaulted + * with PTEs to respect SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + if (ret && !shmem_mapping(folio->mapping)) { + try_to_unmap(folio, ttu_flags); + WARN_ON(folio_mapped(folio)); + } + + return ret; +} + /* * Handle partial folios. The folio may be entirely within the * range if a split has raced with us. If not, we zero the part of the @@ -226,7 +252,7 @@ bool truncate_inode_partial_folio(struct min_order = mapping_min_folio_order(folio->mapping); split_at = folio_page(folio, PAGE_ALIGN_DOWN(offset) / PAGE_SIZE); - if (!try_folio_split_to_order(folio, split_at, min_order)) { + if (!try_folio_split_or_unmap(folio, split_at, min_order)) { /* * try to split at offset + length to make sure folios within * the range can be dropped, especially to avoid memory waste @@ -250,13 +276,10 @@ bool truncate_inode_partial_folio(struct if (!folio_trylock(folio2)) goto out; - /* - * make sure folio2 is large and does not change its mapping. - * Its split result does not matter here. - */ + /* make sure folio2 is large and does not change its mapping */ if (folio_test_large(folio2) && folio2->mapping == folio->mapping) - try_folio_split_to_order(folio2, split_at2, min_order); + try_folio_split_or_unmap(folio2, split_at2, min_order); folio_unlock(folio2); out: _ Patches currently in -mm which might be from kas(a)kernel.org are mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch mm-truncate-unmap-large-folio-on-split-failure.patch

6 days, 14 hours

1
0
0 0

+ mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory: do not populate page table entries beyond i_size has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kiryl Shutsemau <kas(a)kernel.org> Subject: mm/memory: do not populate page table entries beyond i_size Date: Mon, 27 Oct 2025 11:56:35 +0000 Patch series "Fix SIGBUS semantics with large folios", v3. Accessing memory within a VMA, but beyond i_size rounded up to the next page size, is supposed to generate SIGBUS. Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749 failed due to missing SIGBUS. This was caused by my recent changes that try to fault in the whole folio where possible: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") 357b92761d94 ("mm/filemap: map entire large folio faultaround") These changes did not consider i_size when setting up PTEs, leading to xfstest breakage. However, the problem has been present in the kernel for a long time - since huge tmpfs was introduced in 2016. The kernel happily maps PMD-sized folios as PMD without checking i_size. And huge=always tmpfs allocates PMD-size folios on any writes. I considered this corner case when I implemented a large tmpfs, and my conclusion was that no one in their right mind should rely on receiving a SIGBUS signal when accessing beyond i_size. I cannot imagine how it could be useful for the workload. But apparently filesystem folks care a lot about preserving strict SIGBUS semantics. Generic/749 was introduced last year with reference to POSIX, but no real workloads were mentioned. It also acknowledged the tmpfs deviation from the test case. POSIX indeed says[3]: References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. The patchset fixes the regression introduced by recent changes as well as more subtle SIGBUS breakage due to split failure on truncation. This patch (of 2): Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. Recent changes attempted to fault in full folio where possible. They did not respect i_size, which led to populating PTEs beyond i_size and breaking SIGBUS semantics. Darrick reported generic/749 breakage because of this. However, the problem existed before the recent changes. With huge=always tmpfs, any write to a file leads to PMD-size allocation. Following the fault-in of the folio will install PMD mapping regardless of i_size. Fix filemap_map_pages() and finish_fault() to not install: - PTEs beyond i_size; - PMD mappings across i_size; Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/20251027115636.82382-1-kirill@shutemov.name Link: https://lkml.kernel.org/r/20251027115636.82382-2-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau <kas(a)kernel.org> Fixes: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") Fixes: 357b92761d94 ("mm/filemap: map entire large folio faultaround") Fixes: 01c70267053d ("fs: add a filesystem flag for THPs") Reported-by: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/filemap.c | 28 ++++++++++++++++++++-------- mm/memory.c | 20 +++++++++++++++++++- 2 files changed, 39 insertions(+), 9 deletions(-) --- a/mm/filemap.c~mm-memory-do-not-populate-page-table-entries-beyond-i_size +++ a/mm/filemap.c @@ -3681,7 +3681,8 @@ skip: static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, struct folio *folio, unsigned long start, unsigned long addr, unsigned int nr_pages, - unsigned long *rss, unsigned short *mmap_miss) + unsigned long *rss, unsigned short *mmap_miss, + bool can_map_large) { unsigned int ref_from_caller = 1; vm_fault_t ret = 0; @@ -3696,7 +3697,7 @@ static vm_fault_t filemap_map_folio_rang * The folio must not cross VMA or page table boundary. */ addr0 = addr - start * PAGE_SIZE; - if (folio_within_vma(folio, vmf->vma) && + if (can_map_large && folio_within_vma(folio, vmf->vma) && (addr0 & PMD_MASK) == ((addr0 + folio_size(folio) - 1) & PMD_MASK)) { vmf->pte -= start; page -= start; @@ -3811,13 +3812,27 @@ vm_fault_t filemap_map_pages(struct vm_f unsigned long rss = 0; unsigned int nr_pages = 0, folio_type; unsigned short mmap_miss = 0, mmap_miss_saved; + bool can_map_large; rcu_read_lock(); folio = next_uptodate_folio(&xas, mapping, end_pgoff); if (!folio) goto out; - if (filemap_map_pmd(vmf, folio, start_pgoff)) { + file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; + end_pgoff = min(end_pgoff, file_end); + + /* + * Do not allow to map with PTEs beyond i_size and with PMD + * across i_size to preserve SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + can_map_large = shmem_mapping(mapping) || + file_end >= folio_next_index(folio); + + if (can_map_large && filemap_map_pmd(vmf, folio, start_pgoff)) { ret = VM_FAULT_NOPAGE; goto out; } @@ -3830,10 +3845,6 @@ vm_fault_t filemap_map_pages(struct vm_f goto out; } - file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; - if (end_pgoff > file_end) - end_pgoff = file_end; - folio_type = mm_counter_file(folio); do { unsigned long end; @@ -3850,7 +3861,8 @@ vm_fault_t filemap_map_pages(struct vm_f else ret |= filemap_map_folio_range(vmf, folio, xas.xa_index - folio->index, addr, - nr_pages, &rss, &mmap_miss); + nr_pages, &rss, &mmap_miss, + can_map_large); folio_unlock(folio); } while ((folio = next_uptodate_folio(&xas, mapping, end_pgoff)) != NULL); --- a/mm/memory.c~mm-memory-do-not-populate-page-table-entries-beyond-i_size +++ a/mm/memory.c @@ -65,6 +65,7 @@ #include <linux/gfp.h> #include <linux/migrate.h> #include <linux/string.h> +#include <linux/shmem_fs.h> #include <linux/memory-tiers.h> #include <linux/debugfs.h> #include <linux/userfaultfd_k.h> @@ -5501,8 +5502,25 @@ fallback: return ret; } + if (!needs_fallback && vma->vm_file) { + struct address_space *mapping = vma->vm_file->f_mapping; + pgoff_t file_end; + + file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE); + + /* + * Do not allow to map with PTEs beyond i_size and with PMD + * across i_size to preserve SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + needs_fallback = !shmem_mapping(mapping) && + file_end < folio_next_index(folio); + } + if (pmd_none(*vmf->pmd)) { - if (folio_test_pmd_mappable(folio)) { + if (!needs_fallback && folio_test_pmd_mappable(folio)) { ret = do_set_pmd(vmf, folio, page); if (ret != VM_FAULT_FALLBACK) return ret; _ Patches currently in -mm which might be from kas(a)kernel.org are mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch mm-truncate-unmap-large-folio-on-split-failure.patch

6 days, 14 hours

1
0
0 0

[PATCH] thermal/of: Fix reference count leak in thermal_of_cm_lookup

by Miaoqian Lin

The function calls of_parse_phandle() to get a device node, which increments the reference count of the node. However, the function fails to call of_node_put() to decrement the reference. This leads to a reference count leak. This is found by static analysis and similar to the commit a508e33956b5 ("ipmi:ipmb: Fix refcount leak in ipmi_ipmb_probe") Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/thermal/thermal_of.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c index 1a51a4d240ff..932291648683 100644 --- a/drivers/thermal/thermal_of.c +++ b/drivers/thermal/thermal_of.c @@ -284,8 +284,12 @@ static bool thermal_of_cm_lookup(struct device_node *cm_np, int count, i; tr_np = of_parse_phandle(child, "trip", 0); - if (tr_np != trip->priv) + if (tr_np != trip->priv) { + of_node_put(tr_np); continue; + } + + of_node_put(tr_np); /* The trip has been found, look up the cdev. */ count = of_count_phandle_with_args(child, "cooling-device", -- 2.39.5 (Apple Git-154)

6 days, 17 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror