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

Alexander Gordeev <[email protected]> Wed, 29 Jul 2026 12:13:18 +0200
Newsgroups org.kernel.vger.linux-parisc,dev.linux.lists.damon,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.kernel.vger.bpf,org.kernel.vger.linux-arch,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-trace-kernel,org.kvack.linux-mm,org.xenproject.lists.xen-devel
Message-ID <[email protected]>
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?

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

> -- 
> Cheers,
> 
> David

Thanks!