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

[Muhammad Usama Anjum <usama.anjum@arm.com>]

On 29/07/2026 12:05 pm, David Hildenbrand (Arm) wrote:
> 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.
Yeah and architecture cannot opt-in until its converted. So we should leave
it to architecture to define hw_pte_t.

> 
>>
>> 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.
> 

-- 
Thanks,
Usama