Re: mm: opaque hardware page-table entry handles

[Muhammad Usama Anjum <usama.anjum@arm.com>]

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?

-- 
Thanks,
Usama