From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6B293101D0; Tue, 14 Jul 2026 10:51:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784026278; cv=none; b=FPtk9PRMKqkfEMwlz6KGZsXSWcFZiS/ZmiL7WCyTjQOiGoaW9yIXJlJhhwpYnmUjLaLFWDIdH7C0zhBxuuYY7mUdUeBL3V8CZEbvxymCzZ1fzK/tCdiAKbV5/VA9QhGnXmaZ2xWq3aCc/FympokDJH0FdSKOuAujeFGGOujvuEk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784026278; c=relaxed/simple; bh=alYSUYi8wM8SYw1LQzaVPM1YGu7k+aTmp63vD0aHMp4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SmxOPfepDb/s5laHyIbZBGiwva615d/eWAEKIC8QNo9aZLXBX2CivM5x/m/f2N7+y9B1JTpjO6E7sGdO/0C9foRra47P8OcNKKQLHgxZ8/mkebp3RcxBAvW3ToRj8qT66KatfTq10UcswF4vqcLOYZmMrh+nGhmpdwA/0EQnD0U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MlApThBt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MlApThBt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 052DA1F000E9; Tue, 14 Jul 2026 10:51:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784026276; bh=OxQpQzldKM49EBEIXkjKJ1NANB1mGQNgBZQ+0X2NH5Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=MlApThBtkcAbBeEHE6wb62Osko17Mw0QnT3nbVowFnB1oRh6aa8Ly7C8Ysu5Hw/wP CfJYWv6i0jwtALp4tNNYfmmWIqbLtdb3mrR4J/ZgGLHptlIVYe1DBV0HmBg1rXtrXL xj4vTDVVRTgNo4xoRukP+caJwFTHV+LI6w4ycR0SaAshwdTucSgX1u3pB3Uwo1y8gs ilSt6m7Y2Bo+ftZKATtAmo7svFOgusGXuN27x2pOZytqD5cIngQNFtHKKIoln+fOAc 7QL13i2jRiR3ouzyxGvLx8KrBqe/hptepPOaYyB7/E7G0A4pt1tbKx5jFTBVZcSxs8 6ipui5WEx0lsw== Message-ID: Date: Tue, 14 Jul 2026 12:50:59 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 10/34] x86: mm: carve out the generic compile-time folded pgtable case in effective_prot() To: Dave Hansen , Yeoreum Yun , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-arch@vger.kernel.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, linux-csky@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-openrisc@vger.kernel.org Cc: linux@armlinux.org.uk, akpm@linux-foundation.org, ankur.a.arora@oracle.com, rppt@kernel.org, linmag7@gmail.com, chleroy@kernel.org, klarasmodin@gmail.com, chenhuacai@kernel.org, kernel@xen0n.name, kas@kernel.org, zhangtianyang@loongson.cn, wangyuli@aosc.io, tsbogend@alpha.franken.de, ljs@kernel.org, jgg@ziepe.ca, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, ryan.roberts@arm.com, pasha.tatashin@soleen.com, rmclure@linux.ibm.com, baolin.wang@linux.alibaba.com, tj@kernel.org, kevin.brodsky@arm.com, anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@kernel.org, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, hannes@cmpxchg.org, mhocko@kernel.org, qi.zheng@linux.dev, shakeel.butt@linux.dev, kasong@tencent.com, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, anshuman.khandual@arm.com, yang@os.amperecomputing.com, chaitanyas.prakash@arm.com, ardb@kernel.org, guoren@kernel.org, yang.li85200@gmail.com, viro@zeniv.linux.org.uk, dinguyen@kernel.org, schuster.simon@siemens-energy.com, wangruikang@iscas.ac.cn, junhui.liu@pigmoral.tech, muchun.song@linux.dev, vishal.moola@gmail.com, namcao@linutronix.de, pavel@kernel.org, djbw@kernel.org, yu-cheng.yu@intel.com, baolu.lu@linux.intel.com, Jonathan.Cameron@huawei.com, coxu@redhat.com, andreas@gaisler.com, liam@infradead.org, vbabka@kernel.org, surenb@google.com, mhocko@suse.com, geert@linux-m68k.org, shorne@gmail.com, jonas@southpole.se, stefan.kristiansson@saunalahti.fi References: <20260713135614.1618183-1-yeoreum.yun@arm.com> <20260713135614.1618183-11-yeoreum.yun@arm.com> <710b7eb0-8e0c-4f07-991c-2285c77e1beb@intel.com> <6007625e-c3f9-4ad6-99a8-61396bccbcec@kernel.org> <32d459d1-ad19-4baf-bbb1-0565458001d2@intel.com> <3ea30f8a-bb29-4bf5-8400-1c4840d46a88@kernel.org> <7e84b200-25eb-43a6-b5e2-5f27f2d82a77@intel.com> <31988089-095a-4eed-b5e2-c677c70f79f6@kernel.org> <14e250db-1641-4085-8d13-02f819657d5f@intel.com> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <14e250db-1641-4085-8d13-02f819657d5f@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/13/26 23:40, Dave Hansen wrote: > On 7/13/26 14:17, David Hildenbrand (Arm) wrote: >>> To me, the double READ_ONCE() is a non-issue. >> To other arch maintainers, it is! > > Ahh, so it seems like Christophe in ppc32 land was looking at this more > like a regression that needed to get fixed. Yes, exactly. :) And I agree that it is something we should be optimizing. > > Christophe, just out of curiosity, was this something that was causing > you practical problems like measurable performance regressions, or was > it really just insane code generation that seems unacceptably suboptimal? I'd be curious about that as well. I mean, looking at the generated code it's clear that it is suboptimal. The solution space I see: (1) Pass the result from e.g., pgdp_get() into p4d_get(), so it can just return the value with folded p4ds. That requires extreme amounts of churn in core-mm AFAIKS, so I don't see that as feasible. (2) Rewrite folding code to make p4d_present() be a dummy instead of pgd_present(), and make p4dp_get() return a dummy value. ... a lot of churn across architectures. I'm sure we'll learn soon why it was done ike the way it is today in the first place. Something interesting to look at, certainly, but a bit of a stretch just to optimize reads. (3) Make folded pgdp_get() use an ordinary read instead of a READ_ONCE / dummy. I don't like that, because we couldn't catch easily if the value is then actually used some old/new code. If pgd_present() etc are supposed to ignore the value, I'd rather have a mechanism that enforces that the values are actually ignore in pgd_offset() etc as well. (4) What we do in this series, but instead of forbidding set_pgd(), make it only complain when we are passing in a dummy value. The expectation is that it would avoid touching most architecture code in patch 12 -> 27 and still prevent mistakes in the future. @Yeoreum can you play with that and see what the end result would be? The problem of how to handle ptdump effective_prot remains. Which is unfortunately an x86 32-bit only problem ;) ... and effective_prot is essentially an x86-only thing. There are various ways we could handle that, my preferred one would be diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fb298e2191792..3d56e48fe4151 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -96,7 +96,7 @@ config X86 select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE select ARCH_HAS_PMEM_API if X86_64 select ARCH_HAS_PREEMPT_LAZY - select ARCH_HAS_PTDUMP + select ARCH_HAS_PTDUMP if X86_64 select ARCH_HAS_PTE_SPECIAL select ARCH_HAS_HW_PTE_YOUNG select ARCH_HAS_NONLEAF_PMD_YOUNG if PGTABLE_LEVELS > 2 Another option would be to keep the behavior unchanged: diff --git a/mm/ptdump.c b/mm/ptdump.c index 5851096e6f656..ce2cf5e07ac0a 100644 --- a/mm/ptdump.c +++ b/mm/ptdump.c @@ -39,6 +39,9 @@ static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr, return note_kasan_page_table(walk, addr); #endif + if (mm_p4d_folded(walk->mm)) + return 0; + if (st->effective_prot_pgd) st->effective_prot_pgd(st, val); @@ -62,6 +65,13 @@ static int ptdump_p4d_entry(p4d_t *p4d, unsigned long addr, return note_kasan_page_table(walk, addr); #endif + if (mm_pud_folded(walk->mm)) + return 0; + + /* Simulate old behavior: all page table levels exist with folded values. */ + if (mm_p4d_folded(walk->mm) && (st->effective_prot_pgd)) + st->effective_prot_pgd(st, __pgd(p4d_val(val))); + if (st->effective_prot_p4d) st->effective_prot_p4d(st, val); @@ -85,6 +95,15 @@ static int ptdump_pud_entry(pud_t *pud, unsigned long addr, return note_kasan_page_table(walk, addr); #endif + if (mm_pmd_folded(walk->mm)) + return 0; + + /* Simulate old behavior: all page table levels exist with folded values. */ + if (mm_pud_folded(walk->mm) && st->effective_prot_pgd) + st->effective_prot_pgd(st, __pgd(pud_val(val))); + if (mm_p4d_folded(walk->mm) && st->effective_prot_p4d) + st->effective_prot_p4d(st, __p4d(pud_val(val))); + if (st->effective_prot_pud) st->effective_prot_pud(st, val); @@ -107,6 +126,14 @@ static int ptdump_pmd_entry(pmd_t *pmd, unsigned long addr, return note_kasan_page_table(walk, addr); #endif + /* Simulate old behavior: all page table levels exist with folded values. */ + if (mm_pud_folded(walk->mm) && st->effective_prot_pgd) + st->effective_prot_pgd(st, __pgd(pmd_val(val))); + if (mm_p4d_folded(walk->mm) && st->effective_prot_p4d) + st->effective_prot_p4d(st, __p4d(pmd_val(val))); + if (mm_pmd_folded(walk->mm) && st->effective_prot_pud) + st->effective_prot_pud(st, __pud(pmd_val(val))); + if (st->effective_prot_pmd) st->effective_prot_pmd(st, val); if (pmd_leaf(val)) { Then there would be another option of making x86 simply remembering the first level it got called for. -- Cheers, David