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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 08C28C44508 for ; Tue, 14 Jul 2026 14:35:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0BC16B00BC; Tue, 14 Jul 2026 10:35:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CC33B6B00BE; Tue, 14 Jul 2026 10:35:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B87716B00BF; Tue, 14 Jul 2026 10:35:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7FB6D6B00BC for ; Tue, 14 Jul 2026 10:35:26 -0400 (EDT) Received: from smtpin15.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 64996A0396 for ; Tue, 14 Jul 2026 14:35:25 +0000 (UTC) X-FDA: 84987630210.15.979FB62 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf18.hostedemail.com (Postfix) with ESMTP id B4AD61C0003 for ; Tue, 14 Jul 2026 14:35:21 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PT9p6kVK; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1784039723; b=tEVWmxGOEz4BdMUl/FiRnqQTIzVas8Uut6exftRH5ENQH4m4ZI7h2ikHfo/LZFlfGTvygv Lmd9geGQ+NFjWK1Kzjo0Cz46Xq84QyU1AL5xd1vlCJVVkobHxDAZzF9Lhf5qCjY0PHSZzR b3w6mSRN43Baa8BD1GiRzzS8iYcbZ84= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PT9p6kVK; spf=pass (imf18.hostedemail.com: domain of dave.hansen@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1784039723; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sURjXKQEU11P1bZQJDckgSl422yYEIaZ6fJ2AkKKQmg=; b=7oeQfXRN+zn5chxYZ4y5jlo9RaRP67yR5gz0vPz9vl+g7D7DXUuv7EpCc/k7+uIWS1skPD M4VpbjoHBDJPs28w9z4CDZp6rNJJBDZI3xQRYUb1W/jzsMZ/CFnsB+PqNTDVRcLGX+Pi2j QcoAiMGYHsrevtbLlkkoxVSMroWp8wE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1784039722; x=1815575722; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=i5/E15ZfVaqiuuKoJQ87M+N/djH9xHCxPqEUyKVfGrw=; b=PT9p6kVKBMseeEazonXCoMabpg9Kq3yoJq3rwwuRxudATf1Q8mCLRxe1 B0C3O6MYlB+MSnGZGkAB5bsL/PVamgNn/bDEZsKGC61KTdHaO90azKKPc L6NocDan1pxFJNHyPbm5ZDfJThN3ZhnyjPvKW1bDvMgBvkexrFXIUigV/ N3Wv8pe1nN5KI+3vha3THTZFRTYo3UuOcD0iA51QVnxhDrhr7xj3zZ9rS VjI1yaUv2ZGcNM/bqBbqhUzHymQekDvWgGlv9MnsFw9zDU8QmpjTtIcGn NGopm7jSabJxE5yrxI074c/rdV98ONMZo1r8uNPAOc8iBAnb4pT6B8Zcj A==; X-CSE-ConnectionGUID: HUtRH4ouSseFmUIugJu1VQ== X-CSE-MsgGUID: ktrTbQ5VTXW+WYbp/Pmm6A== X-IronPort-AV: E=McAfee;i="6800,10657,11846"; a="95015709" X-IronPort-AV: E=Sophos;i="6.25,163,1779174000"; d="scan'208";a="95015709" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 07:35:18 -0700 X-CSE-ConnectionGUID: 5hRFZimjRjCWuRRr57rVCw== X-CSE-MsgGUID: RKPE0CprSrCJXONJSEZTnw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,163,1779174000"; d="scan'208";a="254749396" Received: from aschende-mobl.amr.corp.intel.com (HELO [10.125.108.120]) ([10.125.108.120]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2026 07:35:17 -0700 Message-ID: <6df814c9-405c-48d8-96ea-929c4b28949b@intel.com> Date: Tue, 14 Jul 2026 07:35:19 -0700 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: Yeoreum Yun , "David Hildenbrand (Arm)" Cc: 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, 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: <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: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B4AD61C0003 X-Stat-Signature: zf5hz4bst5phti33wxrhcuhx4xfkfz7z X-HE-Tag: 1784039721-661523 X-HE-Meta: U2FsdGVkX19cLa+6T2NBLQ7jKLP3k/D0JGm62PfItUhWSuiV2r40ScVPJmxT97q93uJnwR2MtNmE1W39Lp1LomXyPf5EIEqqBUXAafBRS1V4P7KP7rFp5sO8erwTJutWXZRlqrcoON+mjkRaOnyhAp1xsizqkN0rjLwPVPfiYwrxUEy7iKHTV0s4b7+e8gLhEPMNOKsATARiA1LHXDBxyxxDnxdxdDZfKIZvxXukPKizyAVb6LLzZR6AWNH7Gaz/tPkzV7zSifzuVAq77ZCVNx74NAu2m+Krd1bzbr0LPipYRKXk9wl+/5G2OmYN6o0cntKKhmJyfrDql1aXDfhRUq7hcOkOPqjkr88ESFTrQtTvajDM25x4xYtNT3MEe5cTVauqp4bnGI1wHALPAFJxJ6vgU1kxYQanhucpRHjvUDgnCdAUVkT/HTEG23Ihlm2w8PQrQNdopXHQDervQJRrnTFpu3Vqo9nHPW1MYYBmr8EXt53CLxoR/BmODsYLhR+RUTiMj6LYIRKz6rjkSxVsoDF3NMDExYcIbuQlBlKWB+l7WYZeVfZHjYqvGYr/Nx+JZ+8aGsVYoWPZSOpjFRbLPbMiu5V5dlXxwBvl+g3pTWtnzbCjERCv6UN56/eCk+v/lzKr9Q7nGpXwU4d/upFfCu6gU14pWbc+sjWt6d1XDMFktJGIXSVtSZbbkyUK1jsyyH1z3R/+RHQR/b63AXc7jX8r/N/XEwdvVGDgAGCNE+2JsdaaLiCLTBxXTxf/VorbBxKVH5oowPPhMuL1AG14JPBLSerH3MamWug718ACaBXzKy0nlEhyIMazeSmHz9RxHj/FWa9ojdrEQb5Rt34mSUfhmT8xpKr1oL11zp32dBOEuQ0YRcnN7HggZIMPiZAtC93oZsQmeRF8sexy+urN827XwaJGRSFD6EvDxt/Tft8qzSgn8x3d+2+4rXvME5taOnS5lg/7Ojf9YBCyOAH wKLi/IoM BZ6YeQSbMRTyiIaxhBsqevEu/hi3ovbkyP46dmj6HnyCJTezbD5PTdiUxt59c4jo9MBTB52XvYji9wyqnneZ+vCtneAXMP5ksxiT5bS7p9hTFVAxtRhiP8AZp3J2zVfUJjbqfMa1rykkMIkqVo7LMlUQY/z8P/eVTyK4Sy8+l7I+MVQQCE/tSfK9Ul4VSW6EoS3qvitAfE7aeNmqPwJnFUAwHVO4bp/UaOvfK0m7PXJwg8HQ18C1XqPXY5e3X5+mjLVmqVVPspFO6wyYB6Fq1wcBXB5YNGwX44f6XKOrXhvYn7PlHzzrxtsuqwE3C8QP43F0CxRHCbLJ18Rc= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 7/14/26 04:40, Yeoreum Yun wrote: > @@ -254,22 +255,8 @@ static void effective_prot(struct ptdump_state *pt_st, int level, u64 val) > struct pg_state *st = container_of(pt_st, struct pg_state, ptdump); > pgprotval_t prot = val & PTE_FLAGS_MASK; > pgprotval_t effective; > - bool first_level = false; > > - /* Ignore folded levels ... */ > - if (((level == 0) && mm_p4d_folded(st->mm)) || > - ((level == 1) && mm_pud_folded(st->mm)) || > - ((level == 2) && mm_pmd_folded(st->mm))) > - return; > - > - /* ... and make the actual first level remember the protection. */ > - if (((level == 0)) || > - ((level == 1) && mm_p4d_folded(st->mm)) || > - ((level == 2) && mm_pud_folded(st->mm)) || > - ((level == 3) && mm_pmd_folded(st->mm))) > - first_level = true; > - > - if (!first_level) { > + if (first_level > st->first_level) { > pgprotval_t higher_prot = st->prot_levels[level - 1]; > > effective = (higher_prot & prot & (_PAGE_USER | _PAGE_RW)) | > @@ -471,6 +458,15 @@ bool ptdump_walk_pgd_level_core(struct seq_file *m, > .seq = m > }; > > + if (mm_pmd_folded (mm)) > + st->first_level = 3; > + else if (mm_pud_folded (mm)) > + st->first_level = 2; > + else if (mm_p4d_folded (mm)) > + st->first_level = 1; > + else > + st->first_level = 0; > + > ptdump_walk_pgd(&st.ptdump, mm, pgd); This is indeed an improvement and a step in the right direction! Thanks for looking at this. But one of my test for whether it's good x86 code is whether there's any actually x86-specific logic in it. Isn't this basically a translation between the integer level number and whether it is folded? That seems like a common helper that more than one arch could use. Could this be stuck in a helper so that all arch/x86 has to do is: if (mm_pt_level_folded(mm, level)) return; This makes a *ton* of sense in effective_prot() especially. Its entire job is mirroring the hardware's job of inheriting permissions from higher levels of the page tables and enforcing them on lower level leaf entries. If a higher level is folded, there's nothing to inherit. I also think it's worth taking a brief pause on the coding to think about what kind of design would actually be nice here. If the design really is that the pgd is folded, the 'struct mm_walk_ops' code would ideally not even call ->pgd_entry(). It would just (for example) *start* at ->pud_entry() for a 3-level hardware page table. If there are no pgds, why bother calling ->pgd_entry()? It couldn't be done transparently to mm_walk users of course but it could be done incrementally where users move one at a time over to a new scheme. BTW, I'm not saying this needs to be done in this series. But it would be nice to have an eye on the prize.