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

On Wed, Jul 29, 2026 at 01:05:35PM +0200, David Hildenbrand (Arm) wrote:

On 7/29/26 12:13, Alexander Gordeev wrote:

quoted

On Tue, Jul 28, 2026 at 09:26:06PM +0200, David Hildenbrand (Arm) wrote:

quoted

quoted

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.

...

quoted

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.

quoted

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@kernel.org/ (local)

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