From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id AFAC3C44501 for ; Wed, 15 Jul 2026 15:01:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=9Z2zNKjRbgDz18AB/OdbEQN5wpqYTgFBDPBnDwJEk2E=; b=HP7NrTBVcWY6ZNDTeaHiNkOKjT ScabTd83GmXNCL7LHi+6Eju5fxpLieY6272NWQY5KnLfqEXEz7HiK3t68fUHNXYaZHVkN3glklADP OUsHhu4RrNH/dlqpE+qwLwXJTG7SijyJhGtIt3fvGbOid+X7U/or3ku1G7KyKvWdGxE/UwUk84Fr9 ziZ+j459O5XAT6+CKCOxDdn7HYPPeX88bK4Ed3UONqHuwsiN0z+OM7BVZrpFEYR8iRLHjO4Inypj/ 7mz/J92GlLO54AqxW9CxejDGn0l1UFvtYpl4uwx9RS6d0fVrGeVEt2DEj4OEO5P9ZxJR2uNCzR3A0 q/uahMyw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wk17D-0000000FEvo-1cib; Wed, 15 Jul 2026 15:01:39 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wk17C-0000000FEv2-0VoA for linux-arm-kernel@lists.infradead.org; Wed, 15 Jul 2026 15:01:38 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 29ACC6001D; Wed, 15 Jul 2026 15:01:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E95521F000E9; Wed, 15 Jul 2026 15:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784127696; bh=9Z2zNKjRbgDz18AB/OdbEQN5wpqYTgFBDPBnDwJEk2E=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=cPiuISMOHZKbNJ/q+U6zBqKZl6i/54DB+RZCuayF6sI/kqfwtjdaALQ69uJ88Y9Tb t9oj0Gwrjx61elraU/lF3M+8XrCqQFajfZU2mv8YfRrP78r/Wx340y3KQ4iUlEGzM5 eE16z35L/cQdoa8olim+hEXZt4VTFLQlzUnuc/usVzrf89juTGp0WUhVkaElN3dhQx LbUCrcNvso4ErQy0XseZ4PxpaGqrP2jfw6djWjwKyuHqNf1PD0jPkdNqnYsTErA07p qx9E+rQb+xIH6dJ9sMrZ7/kfrX+NQDC/1YbeWlscd9NRHmuuwccHGiNexKkLt5Onau bl+psB0aDqyCw== Date: Wed, 15 Jul 2026 16:01:18 +0100 From: "Lorenzo Stoakes (ARM)" To: Kiryl Shutsemau Cc: Andrew Morton , Suren Baghdasaryan , "Liam R. Howlett" , Vlastimil Babka , Shakeel Butt , David Hildenbrand , Mike Rapoport , Michal Hocko , Uladzislau Rezki , Toshi Kani , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , Will Deacon , Dev Jain , Ryan Roberts , David Carlier , linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org, syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com, Lance Yang Subject: Re: [PATCH mm-hotfixes v2 0/4] mm: fix UAF caused by race between ptdump and vmap pgtable freeing Message-ID: References: <20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@kernel.org> <178404602957.85099.8935151447302412515.b4-reply@b4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org +cc Lance for thanks :) On Tue, Jul 14, 2026 at 06:05:01PM +0100, Kiryl Shutsemau wrote: > On Tue, Jul 14, 2026 at 05:20:29PM +0100, Lorenzo Stoakes (ARM) wrote: > > Basically you need the IRQs disabled to get the semi-RCU behaviour and to > > be able to safely traverse page tables that way. > > > > So with CONFIG_PT_RECLAIM you're safe to RCU traverse PTEs only. > > I think this is stale. Since 1fb3d8c20bfa ("mm/mmu_gather: replace IPI > with synchronize_rcu() when batch allocation fails") the !PT_RECLAIM > fallback is a real grace period -- note your own quote of > __tlb_remove_table_one() calls tlb_remove_table_sync_rcu(), which is > synchronize_rcu() nowadays, not the IPI broadcast. The name invites > the confusion. Ahhh, nice thank you Lance :) > > Together with a37259732a7d ("x86/mm: Make MMU_GATHER_RCU_TABLE_FREE > unconditional") that means every freeing path through the generic > mmu_gather is genuine RCU, batched or not, all levels. A plain > rcu_read_lock() walker is protected; IRQs disabled is not required. Lovely. I'll probably send a patch to fix the comment then :) > > > HAVE_ARCH_TLB_REMOVE_TABLE is set for powerpc, which also enables PTDUMP :) > > and that's because it actually tracks multiple PTE page tables together as > > a fragment. > > sparc also sets it with SMP. So the audit list for custom > tlb_remove_table() implementations is powerpc and sparc -- everything > else gets the generic behaviour above. Yeah. > > No disagreement on the rest: the walker needs > ptep_get_lockless()/pmdp_get_lockless(), and the ppc kernel-side > fragments need a look. Indeed. I know Suren's been taken a look at this, pinged him off-list (he's also cc'd) to see where he's at but I'm going to take a general look at this. I feel that RCU page table freeing is likely to be a requirement for scalable CoW, so directly impacts me :) > > -- > Kiryl Shutsemau / Kirill A. Shutemov Cheers, Lorenzo