Re: [PATCH RFC 00/11] mm: distinguish PTE table storage from PTE values

Re: [PATCH RFC 00/11] mm: distinguish PTE table storage from PTE values

[David Hildenbrand (Arm)]

On 7/27/26 18:46, Muhammad Usama Anjum wrote:
> Hi,
> 
> pte_t currently describes both a logical PTE value and an element stored in
> a PTE table. Consequently, pte_t * can point either to a standalone 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 *. Logical 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, so this series preserves
> the representation and behaviour of every architecture. ptep_get() keeps
> its existing READ_ONCE() semantics and converts the stored element through
> __pte_from_hw(). An architecture can later define a distinct hw_pte_t 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 standalone copied 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.

Do you have a pointer at the arm64 part, so people can get a feeling for how an
actual hw_pte_t implementation can look like.

-- 
Cheers,

David