From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 1DC90359A91; Mon, 28 Sep 2026 07:10:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790579415; cv=none; b=pi6O/5t2TpjOGEBZeWlxACoTpHpSpYWpKW0qnFyRlZ6fNYQfu/Q4Luoz/LjhnmzQwt2P0wJxCjW++tqPEJ1SSR0j3ND+SqOfXBS0OZeGHv2NEqF5Ezy9fYv5puBBo8YPlkWbJJIvamXpg8h5LimnhJErbbfijHIX75zJIlqYp4o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790579415; c=relaxed/simple; bh=S8m7waj7GQq7vgANU2A02JA1/sDnhqqyj+WsYzKQ15U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Opt445CJ+9BxTwPxb/OTNHWmfQxFmO3eej/RcQdQRIj6y5W3CvVD8QLuOrlfihdjWnvsYUopGzN8eiAE0NTOIB6FcgZN29nkBg8mLOcXI8U0TMROjSAUQfMdiqtJiLDoohO7weUy7sOLFgIgacgrhC16XOp+FqUZ1ZUryFi1YW4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=JYy+c8Ji; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="JYy+c8Ji" Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68R9anIw371552; Mon, 28 Sep 2026 07:09:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=U0Sqv66/lUO5fAJlL+QxeO6e18NIiL tdJqIDVEF6pVo=; b=JYy+c8JiVYKn8nouxfqxB62qRnE0w0KFaFzXksbh7vvAEL eXgYsBXTK2Q0/JC4VwMEh9Wwlyt0fkmlrYPk1hebyUUZnJr+feU7zZpKKCD/32/6 GK32iuw74mDOqGX9iyfseMbRfLesf50WlGakV+9f53EZhKFMhbtEbO51ZWCt+ock /PE0Naan+UboeuNsatwP0qFylAPQ++Gg00G3nbQ/ri9MiOMUdZAZg7Or0NU9fxZX ewY6U6oBpIPo40E24MB0d6khSx9MkPg5zQ/6dsPbXRMVmqVFlHA8hhWnrPeRjvWF fheZ3R2ZDqUdhLBF01FckKKwv6/BTpjfJaIy8tMw== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gx5qqyugb-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 28 Sep 2026 07:09:36 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 68S2DNPO2055623; Mon, 28 Sep 2026 07:09:35 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gxrcpmaf5-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Sep 2026 07:09:35 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 68S79W8M49217996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Sep 2026 07:09:32 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 602C620043; Mon, 28 Sep 2026 07:09:32 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DAF6620040; Mon, 28 Sep 2026 07:09:30 +0000 (GMT) Received: from tuxmaker (unknown [9.87.85.9]) by smtpav04.fra02v.mail.ibm.com (Postfix) with ESMTPS; Mon, 28 Sep 2026 07:09:30 +0000 (GMT) Date: Mon, 28 Sep 2026 09:09:29 +0200 From: Alexander Gordeev To: Muhammad Usama Anjum Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Xu Xin , Chengming Zhou , Jann Horn , Muchun Song , Oscar Salvador , Pedro Falcato , Arnd Bergmann , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Peter Zijlstra , Pasha Tatashin , Rik van Riel , Harry Yoo , Lance Yang , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Uladzislau Rezki , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Ian Rogers , Adrian Hunter , James Clark , SJ Park , "Matthew Wilcox (Oracle)" , Jan Kara , Jason Gunthorpe , John Hubbard , Peter Xu , Leon Romanovsky , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Miaohe Lin , Naoya Horiguchi , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Dennis Zhou , Tejun Heo , Christoph Lameter , Johannes Weiner , Qi Zheng , Shakeel Butt , Axel Rasmussen , Yuanchu Xie , Wei Xu , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , David Airlie , Simona Vetter , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-perf-users@vger.kernel.org, damon@lists.linux.dev, kasan-dev@googlegroups.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, xen-devel@lists.xenproject.org Subject: Re: [PATCH v3 0/9] mm: distinguish HW PTE pointers from SW PTE value pointers Message-ID: <20260928070929.80522Ae0-agordeev@linux.ibm.com> References: <20260922-pte0-v3-0-5670b8cb9059@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260922-pte0-v3-0-5670b8cb9059@arm.com> X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTI4MDAyOCBTYWx0ZWRfX1pNoJaF/6NGg RzCzEVkloQ8W8G9Mfqxa0HS4wxj4F16KoDkDBS2dSFD87AGlB8fAZ5HRatX+2wTRelFy0SakY1h egIU9IaRjEc5iG2YlsUx0niBoZ+ODc3IrDwlpj2sQjhlsLXHTrd+qFnF3VG6du2x8khckao6ph2 atPiU8Bg+BUSTPHs0ZaAiWTtqPgIcgw1J/zTT9ypdxsSKELJ2V/SZShJa+6icCLTewI4Ua3C4in kRH925yDQf0TwuALYn9JOVxlJg9GFQA8H7rd/AWjQSWzeO4KnjJldGVe8O6q0dQwbLjnHqb67yV kQCihC/eqkUdKjZb9B04fM4h3PeGZZ9U5PrYd77rO5XeLtrpndiXWd9UC7Kz/QDkx6I810b7lBL UUjG/EFop9zPSO7uVx3xr52sSy3HItoA1LAdosRDqEku61TDVHKyGnttYQJE2xIBCzlH/T5Qbjp rkSOVaMpWaw5iTTVXqA== X-Authority-Analysis: v=2.4 cv=SPbXx+vH c=1 sm=1 tr=0 ts=6aba12b0 cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=kj9zAlcOel0A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=VwQbUJbxAAAA:8 a=7CQSdrXTAAAA:8 a=VnNF1IyMAAAA:8 a=B2JZ75edH0TnST5CdBoA:9 a=CjuIK1q_8ugA:10 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-ORIG-GUID: PXCQtZdXSg0cuRLIZWyjDDo_C9n9y6sW X-Proofpoint-Spam-Info: AW1haW4tMjYwOTI4MDAyOCBTYWx0ZWRfX2//Hh8riVMNP 1wV4C8msuSw0uoDVUiQbJPMpuXHL+T9TmtiZ8EIuMk20HeRVXU+DWNrh28iJ859A2ROV6UZN+vb jTDaorfXlivhY+gjSY6oV8TolRxUfmE= X-Proofpoint-GUID: PXCQtZdXSg0cuRLIZWyjDDo_C9n9y6sW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-26_05,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 clxscore=1015 spamscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 bulkscore=0 impostorscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609280028 On Tue, Sep 22, 2026 at 06:12:28PM +0100, Muhammad Usama Anjum wrote: > Hi, > > pte_t currently describes both a software PTE value and an element stored > in a PTE table. Consequently, pte_t * can point either to a software PTE > value, often a stack copy, or to a PTE-table slot. The compiler cannot > distinguish these cases. A value pointer can therefore be passed to an > interface that expects table storage, while table storage can be read by > direct dereference instead of the architecture accessor. > > This series begins a staged conversion at the PTE level. It introduces > hw_pte_t as the element type for PTE-table storage and converts generic > MM to use hw_pte_t *. Software PTE values remain pte_t. Interfaces that > intentionally return a value through pte_t *, such as install_pte, > remain value interfaces; the relevant parameters are named ptentp to > make that distinction explicit. > > The generic definition aliases hw_pte_t to pte_t unless an architecture > selects ARCH_HAS_HW_PTE_T, which enables a distinct generic wrapper named > __hw_pte_t. Some architectures define pgtable_t in headers parsed before > the generic hw_pte_t typedef is visible. The structure tag allows those > headers to define pgtable_t as struct __hw_pte_t * without creating an > include-order dependency. This is required when converting s390, m68k, > powerpc and sparc. > > No architecture selects ARCH_HAS_HW_PTE_T in this series, so the > representation and behavior of every architecture are preserved. ptep_get() > keeps its existing READ_ONCE() semantics and converts the stored element > through __pte_from_hw(). An architecture can later select the option and > convert its PTE interfaces to make the distinction compiler-enforced. > Architecture PTE implementations and most architecture code are > deliberately left for those later opt-in conversions. > > Here, hw_pte_t identifies PTE-table storage rather than table lifetime: > complete PTE tables use hw_pte_t whether or not they are currently > linked into a page-table hierarchy, while software PTE values use > pte_t. The distinction between complete but unlinked tables and > hardware-reachable tables was raised during discussion and remains an > important point for review. > > PMD, PUD, P4D and PGD storage are deliberately out of scope. They can be > converted in later series after the PTE boundary is agreed, avoiding the > PMD-specific cases that made an all-level conversion difficult to > review. > > Most mechanical pointer conversions were generated with the Coccinelle > script included below, then audited and fixed by hand. > > This series does not add a second ptep_get_once() accessor and does not > remove or replace STRICT_MM_TYPECHECKS. > > The design discussion is available at [1]; while the original idea came > from [2]. > > I've the patches here [3] for arm64 conversion which I used to find > usages in generic code which I missed during development. > > [1] https://lore.kernel.org/all/6110202c-057b-4701-8c04-1a76ee7bb9ab@arm.com/ > [2] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com > [3] https://lore.kernel.org/all/20260914-pte0_arm-v1-0-bb53b663e396@arm.com > > Testing: > Testing was performed with and without the series on both x86_64 and > arm64. KUnit and the MM kselftests produced matching before-and-after > results problems or regressions. Fastpath performance testing was also > completed on arm64. No regression was found. > > Thanks, > Usama ... > Muhammad Usama Anjum (9): > mm: introduce hw_pte_t for PTE table storage > mm: rename pointers to software PTE values as ptentp > mm: use hw_pte_t for generic PTE table storage > mm: convert PTE table entries in ptep_get() > mm: convert PTE table entry to pte > mm: add hw_pte_val for HW PTE storage > mm/kasan: use hw_pte_t for the early shadow PTE table > drm/i915: use hw_pte_t for PTE range callbacks > xen: use hw_pte_t for PTE range callbacks > > MAINTAINERS | 1 + > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 4 +-- > drivers/gpu/drm/i915/i915_mm.c | 4 +-- > drivers/xen/gntdev.c | 2 +- > drivers/xen/privcmd.c | 2 +- > drivers/xen/xenbus/xenbus_client.c | 2 +- > drivers/xen/xlate_mmu.c | 4 +-- > fs/hugetlbfs/inode.c | 3 +- > fs/proc/task_mmu.c | 33 ++++++++++---------- > include/asm-generic/hugetlb.h | 15 ++++----- > include/asm-generic/pgalloc.h | 6 ++-- > include/asm-generic/tlb.h | 5 +-- > include/linux/hugetlb.h | 53 +++++++++++++++++-------------- > include/linux/kasan.h | 2 +- > include/linux/mm.h | 26 ++++++++-------- > include/linux/page_table_check.h | 10 ++++-- > include/linux/pagewalk.h | 10 +++--- > include/linux/pgtable.h | 81 +++++++++++++++++++++++++----------------------- > include/linux/pgtable_types.h | 23 ++++++++++++++ > include/linux/rmap.h | 2 +- > include/linux/swapops.h | 6 ++-- > include/linux/vmalloc.h | 4 +-- > include/trace/events/xen.h | 10 +++--- > kernel/bpf/arena.c | 9 +++--- > kernel/events/core.c | 3 +- > mm/Kconfig | 3 ++ > mm/damon/ops-common.c | 2 +- > mm/damon/ops-common.h | 2 +- > mm/damon/vaddr.c | 20 ++++++------ > mm/debug_vm_pgtable.c | 2 +- > mm/filemap.c | 4 +-- > mm/gup.c | 9 +++--- > mm/highmem.c | 15 ++++----- > mm/hmm.c | 6 ++-- > mm/huge_memory.c | 4 +-- > mm/hugetlb.c | 60 ++++++++++++++++++----------------- > mm/hugetlb_vmemmap.c | 13 ++++---- > mm/internal.h | 16 +++++----- > mm/kasan/init.c | 14 ++++----- > mm/kasan/shadow.c | 6 ++-- > mm/khugepaged.c | 50 ++++++++++++++++++------------ > mm/ksm.c | 11 ++++--- > mm/madvise.c | 18 ++++++----- > mm/mapping_dirty_helpers.c | 4 +-- > mm/memory-failure.c | 6 ++-- > mm/memory.c | 78 +++++++++++++++++++++++----------------------- > mm/mempolicy.c | 4 +-- > mm/migrate.c | 4 +-- > mm/migrate_device.c | 4 +-- > mm/mincore.c | 4 +-- > mm/mlock.c | 4 +-- > mm/mprotect.c | 19 ++++++------ > mm/mremap.c | 4 +-- > mm/page_table_check.c | 4 +-- > mm/pagewalk.c | 9 +++--- > mm/percpu.c | 2 +- > mm/pgtable-generic.c | 20 ++++++------ > mm/ptdump.c | 4 +-- > mm/rmap.c | 6 ++-- > mm/sparse-vmemmap.c | 22 ++++++------- > mm/swap_state.c | 3 +- > mm/swapfile.c | 5 +-- > mm/userfaultfd.c | 32 ++++++++++--------- > mm/util.c | 2 +- > mm/vmalloc.c | 11 ++++--- > mm/vmscan.c | 6 ++-- > 66 files changed, 457 insertions(+), 375 deletions(-) > --- > base-commit: ead700ca770c82167af32622cf8b68c9f87c3c7c > change-id: 20260914-pte0-6c88f5592d79 I backported this series to the Linus master and tested on s390 with the lazy mmu series applied on top. In case it still counts: Tested-by: Alexander Gordeev > Best regards, > -- > Usama Thanks!