On 11/09/2026 5:55 pm, David Hildenbrand (Arm) wrote: > On 9/3/26 12:29, 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. These would be >> sent separately. > > Unless there is more feedback on the overall approach, the next step for this > is > to have at least one architecture support posted. > > We should only merge this if at least one architecture (better two? :) arm64 > and > s390x? ) would merge the architecture bits. > > That is, we should get an ACK from the arch maintainer son the common code > bits > and the arch bits. >
Thank you for reviewing the series. I've posted the patches for arm64 just now [1]. Let's wait for arm64 maintainers to ACK the patches. [1] https://lore.kernel.org/all/[email protected] -- Thanks, Usama
