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 2203FC43458 for ; Sun, 12 Jul 2026 08:47:11 +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=a1MWMA2QpYLFA5dD8C1zSTBdj0Wi20F5ZHok0IusreE=; b=yJkTyfQzs0/azaKTkRb8/IDK4K G/cg2Ner1QAaXxMFNi7yeOiB9lRwZzaodHi9BmvBdLgY08c1+2JtxPkfKo2LSB5fHQpdi+hqwxeg6 OjCB8YXrJWJS5OnbTnXcIorMzuXElD345fhN1HO7Wz3i7wo9bcqd1x0p5WnYqtEAHHJLGtcOpnAwd bHcW58nEjQcf24w29XbxuA+hDphCAyDqxKDM6ECjo4VB0ou3zM0pWF4Ep3Qq5EFpCx+wQVLzH58RH N7ICz6Dgli1g9Hrg/lJ7bUPBHcMy2slwG8oidFbl52pw3mZEfTQu+FMZFXS9VpDcBAo0kEmI6Y00+ oKWGUIfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wipq2-00000007HHk-3chy; Sun, 12 Jul 2026 08:47:02 +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 1wipq1-00000007HHT-3uY9 for linux-arm-kernel@lists.infradead.org; Sun, 12 Jul 2026 08:47:02 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 1004C6004E; Sun, 12 Jul 2026 08:47:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E1A11F000E9; Sun, 12 Jul 2026 08:46:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783846020; bh=a1MWMA2QpYLFA5dD8C1zSTBdj0Wi20F5ZHok0IusreE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=iKyVeFHGvqpi5tvmPTHPGcreoOC16jFVlSlDQXyYi1SCf5+0SfRuCjhBLrtFM2O2E Sa0v5LZE7DyioTyLKUVTV5xpuHU12CrnsE8VkvmroSCZVXbH7nHLSyvjrCtxKPnv/z Y0MomN8W5qRajdgD75Nm5Y0y+SDxuZ7BhuHzfh+iIKASoU1MpzDx6Ji2cOS8GsP3B7 kWCzpq8KN5YDpVRLQCgeW365JEGzXC1Ug07LOuiykc8/M4NK86NnLflZTf2py2PjGJ CE/CA22uUsHHViqNcQniCekI4IYsZsZKMcbCc316PdzRyI5MLnEKNyvWJ09tVCbrw9 MYXy2UhrgakUQ== Date: Sun, 12 Jul 2026 09:46:46 +0100 From: Lorenzo Stoakes To: Dev Jain Cc: Andrew Morton , Suren Baghdasaryan , "Liam R. Howlett" , Vlastimil Babka , Shakeel Butt , David Hildenbrand , Mike Rapoport , Michal Hocko , Uladzislau Rezki , Toshi Kani , Catalin Marinas , Will Deacon , David Carlier , Ryan Roberts , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org, syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com Subject: Re: [PATCH 0/2] mm: fix UAF caused by race between ptdump and vmap pgtable freeing Message-ID: References: <20260710-series-vmap-race-fix-v1-0-5b3794c113fe@kernel.org> <8e320b30-9658-4e9f-ac4c-f99dcf855944@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8e320b30-9658-4e9f-ac4c-f99dcf855944@arm.com> 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 On Sun, Jul 12, 2026 at 12:50:08PM +0530, Dev Jain wrote: > Will Deacon had pushed back on a similar approach: > https://lore.kernel.org/all/20250530123527.GA30463@willie-the-truck/ > > Although now when I read back that thread, it feels more so like my > incompetency to convince :) because: No haha not so, I think more like this stuff is fiddly. > > 1. I don't think this pmd_free_pte_page() path is a hot path at all Right, and we don't actually alter that path anyway > > 2. We are doing a try lock which is almost guaranteed to succeed, > so it's not like we are losing out on block mappings Also it's specifically only on when vmap tries to make a mapping huge, and this path is being inconsistent with a convention that already existed - if you manipulate kernel page table mappings that can interact with other page table walkers, you have to take the init_mm mmap lock. > > 3. Any overhead from the try lock will get dominated by the pgtable > page free/TLB flush Yup. > > I guess you did not take the RCU approach because that would put code > into the generic kernel pgtable freeing path. Well a number of reasons: * firstly yes it makes the code path always RCU only to suit a specific debug user as you say :) * Importantly - we risk genuine RCU stall issues, because the ptdump then has to be RCU too over vast ranges. To work around that you have to shard the ptdump walk, make an assumption all callbacks are RCU-safe, and that the sharding suffices to avoid these stalls. It's a ton of complexity and assumptions to account for... vmalloc doing the wrong thing. * It is an established precedent that we mmap lock init_mm for kernel page table walking as per mm/pagewalk.c. It'd require significant rework there and would disallow any future walkers like this if we were to require RCU. * The mmap lock approach is simple, safe, and as you say is only actually required in code paths that manipulate page tables and thus are already not hotpaths. * If there's future work to free vmalloc page tables upon vunmap() (currently it does not), we have a stable, established basis for doing so that again puts the weight of the work on the operation being performed rather than anything else. > > I liked the RCU approach because I hate the fact that ptdump takes > an mmap_write_lock when it is literally only reading the pgtables. Well you have to do that for the userland side, because there could be a concurrent downgraded mmap read lock during an munmap, and the same goes for non-VMA kernel ranges too, so it would have to keep doing that regardless. > But your approach is simpler and fixes the problem at the particular spot > and not hammers the fix into a generic path. So overall, ACK. Thanks! > > > > Lorenzo Stoakes (2): > > mm/vmalloc: acquire init_mm read lock on huge vmap promotion > > Revert "arm64: Enable vmalloc-huge with ptdump" > > > > arch/arm64/include/asm/ptdump.h | 2 -- > > arch/arm64/mm/mmu.c | 43 ++++------------------------------------- > > arch/arm64/mm/ptdump.c | 11 ++--------- > > include/linux/mmap_lock.h | 1 + > > mm/pagewalk.c | 22 +++++++++++---------- > > mm/vmalloc.c | 41 ++++++++++++++++++++++++++++++--------- > > 6 files changed, 51 insertions(+), 69 deletions(-) > > --- > > base-commit: a635d6748234582ea287c5ffeae28b9b23f91c7e > > change-id: 20260710-series-vmap-race-fix-2a4cac988938 > > > > Cheers, > Cheers, Lorenzo