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 | gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.ports.parisc,gmane.comp.emulators.xen.devel,gmane.linux.kernel.mm,gmane.linux.file-systems,gmane.linux.kernel.cross-arch,gmane.linux.kernel.bpf,gmane.linux.kernel.perf.user |
|---|---|
| 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!