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 BF842C982FF for ; Tue, 22 Sep 2026 12:15:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oG00Y4yLTnp78enkwi7zmvgKXzkzCNuUUS6IJHynZQo=; b=HjiY1FLgUUVvgX yYTUWOqWYzBstyjG8QKo1QWiaD5lkZ5C/aZUiHcpGSFwCFrS+PYgJqjnevmCDG9IWnmK0Elszs3y0 Zlcr+GH2xaZJN9OuNdXhr33jDHUb1Nnrz8TAK0Q0UJzqwlPzoE61OPF1d5KWwPcLrPukhdCM07KPi SrT5tqzoJLDvvmFiXQQLKyDfctxEVhU0rY56XXFhOYpXH5inVX6xwZuvD1oC1JKqpFyIpfB9IN19O gJHlC5GlPTsgyDaaPVeL0/KYW9NzVHopZ0HVT20OL2I26ooIbbjNCrllWPHGM3tK9E5JkLTXc81Z3 v0hJu9QpU9Mu/5WQHqHA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x8zP5-00000005HPO-1RqG; Tue, 22 Sep 2026 12:15:19 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x8zP3-00000005HOV-0sSv; Tue, 22 Sep 2026 12:15:17 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 95A18419CD; Tue, 22 Sep 2026 12:15:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 117D71F000FF; Tue, 22 Sep 2026 12:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790079316; bh=gItcWC83jyqQewAzlLEIrIdpVAhf+FBobtBOU1cWYdE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=h3gqLkdxuBoehEGT/VKAAx5lOOZyw0R9ECju20pTUpkGq3CY4/SfkP5Oo8Atj/17P LheKowjELtZHtWEwX8eBKfgrKHJcRi0+O+d1XJm5SNFJeLnSFaLisjCbEBlxeLxjOn 7b+NpgO+ZPXTsbOJUosoddrg+40PBvbsgsGmbY2VSvCJX0WLnI37yVWEjSxgbtaT89 F/0sTPdrQN1xs1nAXdWed32VZcInT1tJCp8N+5WqvK/lF5EAI6+8MCsas5iRPln/rt CkKwC8hH7tDlCqpUlqLBsfISPWksuIen1RI49kVL18Y30A/o4HPBKzvey0Im1JOlMy V88LVj2NYFEMg== Date: Tue, 22 Sep 2026 13:14:52 +0100 From: "Lorenzo Stoakes (ARM)" To: "David Hildenbrand (Arm)" Cc: Andrew Morton , Zi Yan , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Kiryl Shutsemau , Guo Ren , Brian Cain , Geert Uytterhoeven , Dinh Nguyen , Simon Schuster , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Yoshinori Sato , Rich Felker , John Paul Adrian Glaubitz , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Russell King , Vineet Gupta , Michal Simek , Chris Zankel , Max Filippov , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , "David S. Miller" , Andreas Larsson , Richard Henderson , Matt Turner , Magnus Lindholm , Catalin Marinas , Mark Rutland , Huacai Chen , WANG Xuerui , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Madhavan Srinivasan , Michael Ellerman , "Christophe Leroy (CS GROUP)" , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Arnd Bergmann , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jason Gunthorpe , John Hubbard , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org, linux-sh@vger.kernel.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, linux-arch@vger.kernel.org, sparclinux@vger.kernel.org, linux-alpha@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-um@lists.infradead.org, Hugh Dickins , Qi Zheng Subject: Re: [PATCH v3 01/12] mm/huge_memory: zap deposited page tables after an RCU grace period Message-ID: References: <20260911-rcu-pagetable-freeing-v3-0-7b8c86103821@kernel.org> <20260911-rcu-pagetable-freeing-v3-1-7b8c86103821@kernel.org> <467b6599-b73a-4f58-a29a-b6c6d1ffc3a5@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org On Mon, Sep 21, 2026 at 07:13:16PM +0200, David Hildenbrand (Arm) wrote: > On 9/16/26 18:59, Lorenzo Stoakes (ARM) wrote: > > On Wed, Sep 16, 2026 at 04:42:04PM +0200, David Hildenbrand (Arm) wrote: > >> On 9/11/26 21:36, Lorenzo Stoakes (ARM) wrote: > >>> When an anonymous mapping is collapsed for THP, a PTE page table is > >>> 'deposited' with the installed PMD entry. > >> > >> Right. Or when we allocate an anon THP. > > > > That case doesn't interact with page walking though, as they're > > just-allocated right? > > I was surprised to read that page tables deposited during collapse should behave > differently than page tables deposited during allocation :) You'll be super surprised by how VMAs behave when detached vs. attached then ;) > > That's the semantic change you are adding (and that I didn't quite understand > from reading your description): a deposited page table could now get reused and > modified for another page table due to a PMD split, while there might still be > an RCU page table walker walking it. And PMD comparisons (+ proper memory > ordering) have to make sure that we didn't just walk something that doesn't > belong to us. > > [...] > > >> > >> Wait, but wouldn't it be really problematic to punch a page table that is still > > > > Punch? You mean deposit? > > Yes! Ack. > > > > >> being walked into the deposited list where it can just be allocated from another > >> PMD->PTE split? > > > > In general, RCU-only page table walkers are _only_ guaranteed that the page > > tables are not freed from underneath them, as per the cover letter: > > > > "As a result, page table walks can now be performed safely under RCU without > > any risk of page tables being freed underneath a walker. > > > > However, this is the only guarantee that this work provides - page table > > walkers must still ensure that page table entries are as expected > > throughout." > > So far page table walkers never walk deposited page tables. Just like they never > walk freed page tables. > > For *current* lockless page table walkers (IRQs disabled), > tlb_remove_table_sync_one() takes care of that. So there is no such thing as > "walking a page table that was reused in different context (as a page table) in > the meantime". Yup I know. That describes what happens for RCU page table walkers _after_ the changes of course. > > > > > So this series doesn't actually have to answer that :) > > > > But a PTE PTL -> pmd_same() check will flag anything like that, > > a.k.a. pte_offset_map_lock(). > > > > The RCU lock replaces stablisation on stuff other than VMA/mmap or rmap > > lock. > > > > If the walker needs to be sure the PTE is actually valid and belongs to the > > expected walk then further is required. > > > > Alternatively (like GUP-fast) if you wanted to avoid locking at all, IRQs > > off would be required paired with the tlb_remove_table_sync_one() in > > collapse_huge_page(). > > Doing an RCU sync in tlb_remove_table_sync_one() would be the big hammer (I > thought that was discussed with Lance recently). There is also this option: just > allocate a new page table and deposit it, and free the existing page table > through RCU. Hmm yeah big old lump hammer :) I mean I don't see how that could really possibly fly as an option, we have tlb_remove_table_sync_rcu() for !CONFIG_PT_RECLAIM arches (i.e. err... the more 'specialist' ones :) but for those in actual use that sounds a wee bit nuclear. > > Long story short: allowing empty page tables to be freed by RCU is simple. > Allowing empty page tables to be reused while they are still getting walked is > obviously more complicated conceptually. Likely it can be made working, but I'd > hope that we can keep it simpler. I'm not sure it can really safely be guaranteed or it'd involve more lock dependencies or something horrible anyway. But... we don't need to care about any of that.... > > > > > Another strategy could be used I guess with looped checks but it gets a bit > > sketchy with timing etc. > > > > But actually maybe we can avoid all that... > > > >> > >> Note that pgtable_trans_huge_withdraw() just dequeues *some* PTE page table in > >> the list attached to the PMD table. > >> > >> Something is odd here. > > > > ...Since this code path already allocates (the huge folio), so allocation > > here isn't an issue (as long as done outside of lcosk), why not have it > > also allocate a new PTE to deposit and RCU-free the existing PTE instead? > > > > That eliminates the one place in the kernel (afaik) where a > > page-table-walker-visible table can just get yoinked over somewhere else. > > > > Then a lockless PMD check works. > > > > E.g. something like the below? > > Hah! Great minds think alike. ...Because great minds indeed <3 Will respin with that then, thanks! :) > > -- > Cheers, > > David -- Cheers, Lorenzo _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc