Re: mm: opaque hardware page-table entry handles

[Pedro Falcato]

On Fri, Jul 24, 2026 at 11:34:52AM +0100, Muhammad Usama Anjum wrote:
> On 24/07/2026 10:30 am, Pedro Falcato wrote:
> > On Thu, Jul 23, 2026 at 06:01:49PM +0100, Muhammad Usama Anjum wrote:
> >> On 23/07/2026 5:38 pm, David Hildenbrand (Arm) wrote:
> >>>
> >>>> So after the conversion, it doesn't makes sense to keep STRICT_MM_TYPECHECKS
> >>>> around. Please correct me if I'm wrong.
> >>>>
> >>>> This brings another thing in my mind that in ideal world we would just
> >>>> turn STRICT_MM_TYPECHECKS on for all arches all the time. But the problem
> >>>> with it is that STRICT_MM_TYPECHECKS defines pte_t which will stay double
> >>>> meaning still. So we want sort of STRICT_MM_TYPECHECKS with different name
> >>>> and separate stack and hardware types.
> >>>
> >>> I think STRICT_MM_TYPECHECKS is also to avoid catching when passing a pte_t into
> >>> a function that consumes a pmd_t, and vice versa.
> >>>
> >>> STRICT_MM_TYPECHECKS makes the compiler generate worse code today, which is why
> >>> we don't enable it always.
> >>>
> >>>>
> >>>>>
> >>>>> We would like to keep it, and I guess some other architectures too.
> >>>> David had summarized it well. We'll convert generic code to use hw_p*_t
> >>>> types which would be typedef to p*_t for those architectures which don't
> >>>> care about. But if an architecture wants to interpret these types
> >>>> differently or want to make sure the type is enforced and not directly
> >>>> dereferenced, they need to convert the arch code a well. But it can be
> >>>> done slowly.
> >>>
> >>> I think what Alexander meant is: they want to keep STRICT_MM_TYPECHECKS (or
> >>> something that achieves something similar :) ). So as long as that keeps on
> >>> working, all good :)
> >> Thank you for clarifying.
> >>
> >> It has been a month since I started this discussion. We don't have any
> >> disagreement on it. Should I proceed to post first part patch series considering
> >> most people must already have viewed these emails and are on-board with it?
> > 
> > Besides the vague disagreement I have (about whether this is worth it or
> > not), I have an actual objection: I've been doing some constifying of pte_t*
> > for various reasons lately, and something that just just came up is how
> > hw_ptep will _not_ work with const, unless you do something like
> > const_hw_ptep, in which case welcome to Win32 programming or something :|
> > 
> > (I'm assuming the idea still is typedef struct { pte_t *pte; } hw_ptep;)
> We have moved on from this as it was very disruptive. Now we envision the
> following:
> 
> typedef struct {pte_t __pte;} hw_pte_t;
> 
> With this, const wouldn't be a problem.

Ok, great!

> 
> > 
> > Have you tried sparse instead?
> We want to ensure safety during compile time. Without going into more detail,
> more features would be build on top of this type conversion. 

I understand corporate/business goals may be tying your hands together, but
it's really difficult to think about your proposal critically if we don't have
all the details.

-- 
Pedro