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

On 28/07/2026 8:26 pm, David Hildenbrand (Arm) wrote:
> 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.
I've the patches here [1] for arm64 conversion which I used to find usages
in generic code which I missed during development.

[1] https://github.com/musamaanjum/linux/commits/pte0_arm/

I could have posted these patches alongside the generic conversion. But I
thought it would be best to convert generic side first. Please feel free
to let me know if next series should have arm64 side conversion as well.

-- 
Thanks,
Usama