From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793088408; b=d3A9uZVIgzLZy4dFoXnvzi4qIk3whrLAjbkvO2+TiJwuDV7cbO9aglPyk3NYSKhfTDcn 91cCEVNnt74TG9vQ7uZIEUToI8vswtOqwbCKOZHlZ/KgWWZp94gKTMtRbDfr4Rv/otEaK 7KJ7K0WKkFg+yPD7POKxBq4ahT3WcI1Zg9VZUuWh8iwa9NiBeFW3PD/Jhj37XbHTBaeWz tp17LoLQvtzDBZqEWTWSLjP+qY/ZK6aO+23ZqezLSX+qcs4qqKF23nw/0X0qqrMxr3Au+ mUr5C85lTHOHUMd/oZIGGq9djdRuoGQVHHLO92S/EW7/j8RiB1A76Y9967YOfeKR3xA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793088408; h=Received:DKIM-Signature:Date:From:To:Cc:Subject:Message-ID: References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=tGP0LjdymEX/O70OpFiXykL3tGWdkhpJkzQJ0xiHk2s=; b=Rv1xr7XP7BVLfVGrq1IXLf9U6Pt5INF/u8SgNBsIDXEH/C51cxHph4qbIeReE8iHZdwO E4R/jiaGIKqTv1tCQwBHNJK+xjC5iTwbgqGSnpT/cQSFsS6+23/tocK4bpzS9HrjMI5zb klm0kbHpnSJHNWFPX0h/1Lg7qBuQRekuaPnxcd8vTqu1oir2OiJlg+f3jWRwnqPUKQTt/ E4qP62WLWcB8JkLm+JsEgrfU8MPrvRAiUcDi8ridCgu5Cjo+FFt2Trm/grmWXDb2MB6b0 sBh9vmAHJtGkyHT86/0OKk2nuZScGbLF1EqeXfRGh4lzYd6+rPy3NGV/WoYo12Zbt+A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=BoIvLyS4; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5006B606A31A; Tue, 27 Oct 2026 08:06:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=BoIvLyS4 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7669F1F01825; Tue, 27 Oct 2026 08:06:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793088408; bh=tGP0LjdymEX/O70OpFiXykL3tGWdkhpJkzQJ0xiHk2s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=BoIvLyS4BeMWr65hedSikSZ5vE8O9JRgtibUW/piTLatgtmus034g8LURA3R+gHJc ydIDPqS/Oq7d7JsbwgaioD3d1cV8JjOomy7xzfXW42dsVa5rjkstyyKLDXODrEKei/ vB2Qwp8dvj5O3AKG6ZMVvpIywISsqf/obj5nk6KOVMT8qLApC1PN0PM0ZrjYBAf2Xu 5g6N2XtIXQ3TbybogpP04e5dcBVdBVy+cHCzH1jEUnk9T+8vtYavS1rB+QxhcGQdgH FThLB2pNS03O7e0SOprSN4uGF5bozDM1GQt3OLElmNxQv6g/clWdchbL3nMOAmhEFL j+r5zdUmZqxow== Date: Tue, 27 Oct 2026 08:06:31 +0000 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Johannes Weiner , Michal Hocko , Qi Zheng , Shakeel Butt , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , Baolin Wang , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kees Cook , Peter Zijlstra , Jann Horn , Pedro Falcato , Hugh Dickins , Pasha Tatashin , Pratyush Yadav , "Matthew Wilcox (Oracle)" , Jan Kara , Zi Yan , Lance Yang , Rik van Riel , Harry Yoo , Alistair Popple , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Matthew Brost , John Hubbard , Peter Xu , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Oscar Salvador , Minchan Kim , Muchun Song , Xu Xin , Chengming Zhou , Chris Li , Kemeng Shi , Nhat Pham , Youngjun Park , Gregory Price , Joshua Hahn , Rakie Kim , Ying Huang , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, Josef Bacik , stable@vger.kernel.org Subject: Re: [PATCH 01/46] mm/mglru: don't use stack pointers when walking PUD and PMD tables Message-ID: References: <20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org> <20261027-fixes_core-v1-1-6f74bec9a5bb@kernel.org> X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261027-fixes_core-v1-1-6f74bec9a5bb@kernel.org> On Tue, Oct 27, 2026 at 12:17:21AM +0100, David Hildenbrand (Arm) wrote: > From: Josef Bacik > > MGLRU passes stack copies of page-table entries in walk_pud_range() and > walk_pmd_range() when walking to the next level. These copies can become > stale when khugepaged or MADV_DONTNEED (CONFIG_PT_RECLAIM) removes a PTE > table concurrently. > > This pattern dates back to commit bd74fdaea146 ("mm: multi-gen LRU: > support page table walks"). Likely, earlier locking masked the latent > bug. Later changes exposed it: commit 1d65b771bc08 ("mm/khugepaged: > retract_page_tables() without mmap or vma lock") allowed concurrent > retraction, and commit cf4a65539c13 ("memcg-v1: no need for memcg locking > for MGLRU") dropped the walker's outer RCU protection. > > The fix is simple, so just fix the original commit so we don't have to > speculate. To fix it, pass the actual PMD/PUD pointers. This restores the > RCU-protected lookup and validation against the live PMD. Note that the PUD > handling is required as well to handle folded page tables correctly in all > cases. > > Fix generated by an LLM and sent by Josef Bacik in private. > > Fixes: bd74fdaea146 ("mm: multi-gen LRU: support page table walks") > Cc: stable@vger.kernel.org > Signed-off-by: Josef Bacik > [ david: handle walk_pud_range() as well, clarify+simplify description, > adjust Fixes: ] > Signed-off-by: David Hildenbrand (Arm) > --- God, terrible. And why does MGLRU feel it needs its own independent page walking mechanism?... the whole thing feels like NIH syndrome writ large. Anyway, rant aside: Reviewed-by: Lorenzo Stoakes (ARM) > mm/vmscan.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 9959ca158ce83..6a1af9b92349f 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -3911,7 +3911,7 @@ static void walk_pmd_range(pud_t *pud, unsigned long start, unsigned long end, > > walk->mm_stats[MM_NONLEAF_FOUND]++; > > - if (!walk_pte_range(&val, addr, next, args)) > + if (!walk_pte_range(pmd + i, addr, next, args)) > continue; > > walk->mm_stats[MM_NONLEAF_ADDED]++; > @@ -3947,7 +3947,7 @@ static int walk_pud_range(p4d_t *p4d, unsigned long start, unsigned long end, > if (!pud_present(val) || WARN_ON_ONCE(pud_leaf(val))) > continue; > > - walk_pmd_range(&val, addr, next, args); > + walk_pmd_range(pud + i, addr, next, args); > > if (need_resched() || walk->batched >= MAX_LRU_BATCH) { > end = (addr | ~PUD_MASK) + 1; > > -- > 2.43.0 > -- Cheers, Lorenzo