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

["David Hildenbrand (Arm)" <david@xxxxxxxxxx>]

On 7/29/26 12:13, Alexander Gordeev wrote:
> On Tue, Jul 28, 2026 at 09:26:06PM +0200, David Hildenbrand (Arm) wrote:
>>> 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.
> ...
>> 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.
> 
> May be we need the generic hw_pte_t implementation as { pte_t pte; }
> right away?

Indeed, that makes sense. We just need a way for the architecture to opt-in that
it did the conversion.

> 
> Also, can you envision a case when sizeof(pte_t) != sizeof(hw_pte_t)?
> If not, the compile-time check is worth adding.

That wouldn't work as is. We'd have to intercept ptep++ and instead have a
helper to advance the ptep pointer.

One idea for that would be to let the compiler catch that by marking hw_pte_t an
undefined struct (unknown size), such that the compiler would indicate any usage
of ptep++ properly.

That can be done when it would actually required, so as a first step having a
generic hw_pte_t would just work.

-- 
Cheers,

David