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

[Alexander Gordeev <agordeev@xxxxxxxxxxxxx>]

On Wed, Jul 29, 2026 at 01:05:35PM +0200, 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.
> 
> > 
> > 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.

I think I am missing the point. That is my takeaway from your previous mail:
https://lore.kernel.org/lkml/31d36023-d728-4eee-90f8-158c7066f565@xxxxxxxxxx/

<quote>
>    {
>       page_table_check_ptes_set(mm, addr, ptep, pte, nr);
>       for (;;) {
>               set_pte(ptep, pte);
>               if (--nr == 0)
>                       break;
>   -           ptep++;
>   +           ptep = hw_pte_next(ptep);

We should really just let ptep++ work as before.

>               pte = pte_next_pfn(pte);
>       }
>    }
</quote>

So are we going after hw_pte_next(ptep) or ptep++?

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

What is the purpose of that? I mean when pte_t vs hw_pte_t uses are sorted
out what is the benefit of preventing hw_ptep++?

> 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

Thanks!