Re: mm: opaque hardware page-table entry handles

Re: mm: opaque hardware page-table entry handles

[Alexander Gordeev]

On Wed, Jul 15, 2026 at 05:15:36PM +0100, Muhammad Usama Anjum wrote:
> Hi,
> 
> [Moved some already involved people to To. So they can help with the plan
> details mentioned below.]
> 
> On 07/07/2026 2:17 pm, David Hildenbrand (Arm) wrote:
> > [...]
> > 
> >>>
> >>> typedef struct {
> >>> 	pte_t __pte;
> >>> } hw_pte_t;
> >>>
> >>> And then simply use
> >>>
> >>> hw_pte_t *hptep;
> >> Make sense. So you have suggested to just hide put pte_t inside a structure
> >> instead of complex structure of pointer. I've tried to implement and it reduces
> >> churn enormously.
> > 
> > Right. And for most architectures we can probable leave both types be the same
> > under the hood.
> > 
> > So we'd only have to convert common code first, and can then e.g., look into
> > making architectures that care about the difference (e.g., arm64) actually have
> > it be two separate types.
> It makes a lot of sense.
> 
> Let's even divide the series into more parts as there are several places where
> conversion is controversial. (Xi Yan had mentioned one example earlier in this
> thread.) Most of those controversial conversions are pmd related. I propose
> that we convert pte_t first, then pmd_t and others. It'll keep the number of
> patches manageable and easier to review. 
> 
> I think wider agreement for this approach will be very helpful before I post the
> actual code.
> 
> > 
> > Just an idea to further reduce the churn and limit it only to core code (because
> > I saw some very ugly stuff in some arch code that would make such a conversion
> > harder).
> > 
> > [...]
> > 
> >>> Why do we need this and what would we use it for?
> >> The idea was that there should be two different functions to read value. Let's
> >> leave this out of the first initial series. It is complicating the original
> >> proposal.
> > 
> > Right, let's leave that out for now. I'm currently working with Levi on an
> > approach that tries to avoid the overhead due to READ_ONCE with folded page
> > tables. [1]
> So you are referring to page folding improvements. I also stumbled upon those
> while doing a dirty implementation.
> 
> > 
> > We're still struggling with some bits, but looks like we can make it fly and
> > have it be fairly robust.
> > 
> > With that, maybe there is no reason left to have separate pXXp_get() vs.
> > pXXp_get_once(). TBD :)
> Yeah, I was reviewing that series earlier today. I've not looked deeply, but it
> seems there are still a lot of cases where (mostly) pmd is getting dereferenced
> directly. To complete the conversion, direct dereferences need to be converted
> into an API. I've been thinking if there should be a dereference macro or we
> must always use pmdp_get() even though it ensures ordering. It may add excessive 
> ordering in some functions if pmdp_get() is getting called multiple times. But
> storing its output in a tmp variable would solve this. 
> 
> Do you agree with converting all direct dereferences into pXXp_get()?

For the clarity (e.g. on the PTE level) is it goint to be converted to?

pte_t ptep_get(hw_pte_t *ptep);
pte_t set_pte(hw_pte_t *ptep, pte_t pte);

While variables on stack are still may be dereferenced directly via pte_t*?

What about unlinked/temporary page tables in memory?

> > [1] https://lore.kernel.org/all/08ecabe9-0664-4aea-82fb-f9cb1739f762@kernel.org/
> > 
> > [...]
> > 
> >>>
> >>> I'm still not sure about the _once() really, and if we need that right now. We
> >>> survived without is so far, why do we need it now?
> >> The idea is to convert all current pXXp_get() to pXXp_get_once() and convert raw
> >> dereference to pXXp_get(). Let's keep this idea separate for the other work. Let's
> >> discuss it later sometime again later.
> > 

> > Sounds good.
> 
> I've tried to do conversions already. Converting by call hierarchy wise is very
> difficult and error prune.
> 
> Converting component by component (such as page walk, huge page) is also difficult
> as code is tangled. Some helper which is getting used in one component is also used
> in another component.
> 
> I see the following way forward:
> * Add the new type
> * Identify which functions need explicitly pointer to a stack variable. These
>   must not be converted. These variables must be renamed to a common name. For
>   pte_t pointers on stack some functions already use ptentp, which is unique name
>   if we look at generic code. So ptentp would be used for all such variables.
> * One commit per controversial change would be done at this point. We need new
>   separate function for stack types. Also we can do more renaming to a name which
>   will not be converted.
> * Run Coccinelle script directory-by-directory which would ignore converting any
>   ptentp (and similarly for other types). Coccinelle doesn't converts in some case
>   (pte_t *a. *b) which can be done by hand at this point.
> * Update any remaining functions

What is the approach to STRICT_MM_TYPECHECKS?

We would like to keep it, and I guess some other architectures too.

> -- 
> Thanks,
> Usama

Thanks!

Re: mm: opaque hardware page-table entry handles

[Muhammad Usama Anjum]

Hi Alexander,

Thank you for reviewing.

On 21/07/2026 1:40 pm, Alexander Gordeev wrote:
> On Wed, Jul 15, 2026 at 05:15:36PM +0100, Muhammad Usama Anjum wrote:
>> Hi,
>>
>> [Moved some already involved people to To. So they can help with the plan
>> details mentioned below.]
>>
>> On 07/07/2026 2:17 pm, David Hildenbrand (Arm) wrote:
>>> [...]
>>>
>>>>>
>>>>> typedef struct {
>>>>> 	pte_t __pte;
>>>>> } hw_pte_t;
>>>>>
>>>>> And then simply use
>>>>>
>>>>> hw_pte_t *hptep;
>>>> Make sense. So you have suggested to just hide put pte_t inside a structure
>>>> instead of complex structure of pointer. I've tried to implement and it reduces
>>>> churn enormously.
>>>
>>> Right. And for most architectures we can probable leave both types be the same
>>> under the hood.
>>>
>>> So we'd only have to convert common code first, and can then e.g., look into
>>> making architectures that care about the difference (e.g., arm64) actually have
>>> it be two separate types.
>> It makes a lot of sense.
>>
>> Let's even divide the series into more parts as there are several places where
>> conversion is controversial. (Xi Yan had mentioned one example earlier in this
>> thread.) Most of those controversial conversions are pmd related. I propose
>> that we convert pte_t first, then pmd_t and others. It'll keep the number of
>> patches manageable and easier to review. 
>>
>> I think wider agreement for this approach will be very helpful before I post the
>> actual code.
>>
>>>
>>> Just an idea to further reduce the churn and limit it only to core code (because
>>> I saw some very ugly stuff in some arch code that would make such a conversion
>>> harder).
>>>
>>> [...]
>>>
>>>>> Why do we need this and what would we use it for?
>>>> The idea was that there should be two different functions to read value. Let's
>>>> leave this out of the first initial series. It is complicating the original
>>>> proposal.
>>>
>>> Right, let's leave that out for now. I'm currently working with Levi on an
>>> approach that tries to avoid the overhead due to READ_ONCE with folded page
>>> tables. [1]
>> So you are referring to page folding improvements. I also stumbled upon those
>> while doing a dirty implementation.
>>
>>>
>>> We're still struggling with some bits, but looks like we can make it fly and
>>> have it be fairly robust.
>>>
>>> With that, maybe there is no reason left to have separate pXXp_get() vs.
>>> pXXp_get_once(). TBD :)
>> Yeah, I was reviewing that series earlier today. I've not looked deeply, but it
>> seems there are still a lot of cases where (mostly) pmd is getting dereferenced
>> directly. To complete the conversion, direct dereferences need to be converted
>> into an API. I've been thinking if there should be a dereference macro or we
>> must always use pmdp_get() even though it ensures ordering. It may add excessive 
>> ordering in some functions if pmdp_get() is getting called multiple times. But
>> storing its output in a tmp variable would solve this. 
>>
>> Do you agree with converting all direct dereferences into pXXp_get()?
> 
> For the clarity (e.g. on the PTE level) is it goint to be converted to?
> 
> pte_t ptep_get(hw_pte_t *ptep);
Yes, that's correct. 

> pte_t set_pte(hw_pte_t *ptep, pte_t pte);
Yeah, probably it has void type:
void set_pte(hw_pte_t *ptep, pte_t pte);

> 
> While variables on stack are still may be dereferenced directly via pte_t*?
Yes. The conversion would force us to never directly dereference a hardware type.

> 
> What about unlinked/temporary page tables in memory?
I've thought about it multiple times and it is best to represent using hw_p*_t
type. Even though they aren't installed or live, but it makes more sense to use
hardware type as they may get installed soon. 

The difference between representing stack type with pte_t and unlinked/temporary
page table with hw_pte_t is that unlinked/temporary page tables are complete tables
and not just some copied value.

> 
>>> [1] https://lore.kernel.org/all/08ecabe9-0664-4aea-82fb-f9cb1739f762@kernel.org/
>>>
>>> [...]
>>>
>>>>>
>>>>> I'm still not sure about the _once() really, and if we need that right now. We
>>>>> survived without is so far, why do we need it now?
>>>> The idea is to convert all current pXXp_get() to pXXp_get_once() and convert raw
>>>> dereference to pXXp_get(). Let's keep this idea separate for the other work. Let's
>>>> discuss it later sometime again later.
>>>
> 
>>> Sounds good.
>>
>> I've tried to do conversions already. Converting by call hierarchy wise is very
>> difficult and error prune.
>>
>> Converting component by component (such as page walk, huge page) is also difficult
>> as code is tangled. Some helper which is getting used in one component is also used
>> in another component.
>>
>> I see the following way forward:
>> * Add the new type
>> * Identify which functions need explicitly pointer to a stack variable. These
>>   must not be converted. These variables must be renamed to a common name. For
>>   pte_t pointers on stack some functions already use ptentp, which is unique name
>>   if we look at generic code. So ptentp would be used for all such variables.
>> * One commit per controversial change would be done at this point. We need new
>>   separate function for stack types. Also we can do more renaming to a name which
>>   will not be converted.
>> * Run Coccinelle script directory-by-directory which would ignore converting any
>>   ptentp (and similarly for other types). Coccinelle doesn't converts in some case
>>   (pte_t *a. *b) which can be done by hand at this point.
>> * Update any remaining functions
> 
> What is the approach to STRICT_MM_TYPECHECKS?
I've tested after converting couple of arches, it doesn't
break STRICT_MM_TYPECHECKS. I intend to keep STRICT_MM_TYPECHECKS working.
But once the architectures which uses STRICT_MM_TYPECHECKS are converted,
we don't need STRICT_MM_TYPECHECKS anymore as those checks would be enforced
by the conversion itself. Thinking out loud:

Normally:
typedef pteval_t pte_t;

In case of STRICT_MM_TYPECHECKS:
typedef struct { pteval_t pte; } pte_t;

After introducing type conversions:
Normally:
typedef pteval_t pte_t;
typedef struct {pte_t __pte;} hw_pte_t;

In case of STRICT_MM_TYPECHECKS:
typedef struct { pteval_t pte; } pte_t;
typedef struct { pte_t __pte;} hw_pte_t;

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.

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

-- 
Thanks,
Usama

Re: mm: opaque hardware page-table entry handles

[David Hildenbrand (Arm)]

> 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 :)

-- 
Cheers,

David

Re: mm: opaque hardware page-table entry handles

[Muhammad Usama Anjum]

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

Re: mm: opaque hardware page-table entry handles

[Pedro Falcato]

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;)

Have you tried sparse instead?

-- 
Pedro

Re: mm: opaque hardware page-table entry handles

[Muhammad Usama Anjum]

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.

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

-- 
Thanks,
Usama

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

Re: mm: opaque hardware page-table entry handles

[Alexander Gordeev]

On Thu, Jul 23, 2026 at 09:21:32AM +0100, Muhammad Usama Anjum wrote:
> Hi Alexander,
> 
> Thank you for reviewing.
> 
> On 21/07/2026 1:40 pm, Alexander Gordeev wrote:
> > On Wed, Jul 15, 2026 at 05:15:36PM +0100, Muhammad Usama Anjum wrote:
> >> Hi,
> >>
> >> [Moved some already involved people to To. So they can help with the plan
> >> details mentioned below.]
> >>
> >> On 07/07/2026 2:17 pm, David Hildenbrand (Arm) wrote:
> >>> [...]
> >>>
> >>>>>
> >>>>> typedef struct {
> >>>>> 	pte_t __pte;
> >>>>> } hw_pte_t;
> >>>>>
> >>>>> And then simply use
> >>>>>
> >>>>> hw_pte_t *hptep;
> >>>> Make sense. So you have suggested to just hide put pte_t inside a structure
> >>>> instead of complex structure of pointer. I've tried to implement and it reduces
> >>>> churn enormously.
> >>>
> >>> Right. And for most architectures we can probable leave both types be the same
> >>> under the hood.
> >>>
> >>> So we'd only have to convert common code first, and can then e.g., look into
> >>> making architectures that care about the difference (e.g., arm64) actually have
> >>> it be two separate types.
> >> It makes a lot of sense.
> >>
> >> Let's even divide the series into more parts as there are several places where
> >> conversion is controversial. (Xi Yan had mentioned one example earlier in this
> >> thread.) Most of those controversial conversions are pmd related. I propose
> >> that we convert pte_t first, then pmd_t and others. It'll keep the number of
> >> patches manageable and easier to review. 
> >>
> >> I think wider agreement for this approach will be very helpful before I post the
> >> actual code.
> >>
> >>>
> >>> Just an idea to further reduce the churn and limit it only to core code (because
> >>> I saw some very ugly stuff in some arch code that would make such a conversion
> >>> harder).
> >>>
> >>> [...]
> >>>
> >>>>> Why do we need this and what would we use it for?
> >>>> The idea was that there should be two different functions to read value. Let's
> >>>> leave this out of the first initial series. It is complicating the original
> >>>> proposal.
> >>>
> >>> Right, let's leave that out for now. I'm currently working with Levi on an
> >>> approach that tries to avoid the overhead due to READ_ONCE with folded page
> >>> tables. [1]
> >> So you are referring to page folding improvements. I also stumbled upon those
> >> while doing a dirty implementation.
> >>
> >>>
> >>> We're still struggling with some bits, but looks like we can make it fly and
> >>> have it be fairly robust.
> >>>
> >>> With that, maybe there is no reason left to have separate pXXp_get() vs.
> >>> pXXp_get_once(). TBD :)
> >> Yeah, I was reviewing that series earlier today. I've not looked deeply, but it
> >> seems there are still a lot of cases where (mostly) pmd is getting dereferenced
> >> directly. To complete the conversion, direct dereferences need to be converted
> >> into an API. I've been thinking if there should be a dereference macro or we
> >> must always use pmdp_get() even though it ensures ordering. It may add excessive 
> >> ordering in some functions if pmdp_get() is getting called multiple times. But
> >> storing its output in a tmp variable would solve this. 
> >>
> >> Do you agree with converting all direct dereferences into pXXp_get()?
> > 
> > For the clarity (e.g. on the PTE level) is it goint to be converted to?
> > 
> > pte_t ptep_get(hw_pte_t *ptep);
> Yes, that's correct. 
> 
> > pte_t set_pte(hw_pte_t *ptep, pte_t pte);
> Yeah, probably it has void type:
> void set_pte(hw_pte_t *ptep, pte_t pte);
> 
> > 
> > While variables on stack are still may be dereferenced directly via pte_t*?
> Yes. The conversion would force us to never directly dereference a hardware type.
> 
> > 
> > What about unlinked/temporary page tables in memory?
> I've thought about it multiple times and it is best to represent using hw_p*_t
> type. Even though they aren't installed or live, but it makes more sense to use
> hardware type as they may get installed soon. 

My concern is in the long run the dedicated hw_pte_t APIs may want to do something
special with a hw_pXX_t pointers: accounting, HW resources allocation, tracking,
link a shadow, whatever. Some of those might be wrong when applied against a
temporary copy, even though that copy constitutes a formatted page table in memory.

E.g. right now [1] has the following ptep_get() implementation:

#define ptep_get ptep_get
static inline pte_t ptep_get(pte_t *ptep)
{
	pte_t res;

	if (!is_lazy_mmu_active() || !__lazy_mmu_ptep_get(ptep, &res))
		res = __ptep_get(ptep);
	return res;
}

Right now it would not hurt to get called against an unlinked hw_pte_t,
but it is certainly suboptimal.

> The difference between representing stack type with pte_t and unlinked/temporary
> page table with hw_pte_t is that unlinked/temporary page tables are complete tables
> and not just some copied value.

Well, in the past we had linked lists of page tables, which could well
be handled using direct dereferences even after this rework (assuming we
did not removed those lists).

Sorry for bringing up the classification question from your original
message again:

- "a pointer to a live entry in the hardware page table, or
- "the pointer points into real page-table memory and that table is complete,
   whether or not it's linked in yet"

...but the semantics of the former still looks to me stronger than one of
the latter. I am afraid this question is going to pop up time and again.

1. https://lore.kernel.org/linux-s390/71acca838bd3c5bb690ccb4a36313a889a48f383.1784121418.git.agordeev@linux.ibm.com/

> >>> [1] https://lore.kernel.org/all/08ecabe9-0664-4aea-82fb-f9cb1739f762@kernel.org/
> >>>
> >>> [...]
> >>>
> >>>>>
> >>>>> I'm still not sure about the _once() really, and if we need that right now. We
> >>>>> survived without is so far, why do we need it now?
> >>>> The idea is to convert all current pXXp_get() to pXXp_get_once() and convert raw
> >>>> dereference to pXXp_get(). Let's keep this idea separate for the other work. Let's
> >>>> discuss it later sometime again later.
> >>>
> > 
> >>> Sounds good.
> >>
> >> I've tried to do conversions already. Converting by call hierarchy wise is very
> >> difficult and error prune.
> >>
> >> Converting component by component (such as page walk, huge page) is also difficult
> >> as code is tangled. Some helper which is getting used in one component is also used
> >> in another component.
> >>
> >> I see the following way forward:
> >> * Add the new type
> >> * Identify which functions need explicitly pointer to a stack variable. These
> >>   must not be converted. These variables must be renamed to a common name. For
> >>   pte_t pointers on stack some functions already use ptentp, which is unique name
> >>   if we look at generic code. So ptentp would be used for all such variables.
> >> * One commit per controversial change would be done at this point. We need new
> >>   separate function for stack types. Also we can do more renaming to a name which
> >>   will not be converted.
> >> * Run Coccinelle script directory-by-directory which would ignore converting any
> >>   ptentp (and similarly for other types). Coccinelle doesn't converts in some case
> >>   (pte_t *a. *b) which can be done by hand at this point.
> >> * Update any remaining functions
> > 
> > What is the approach to STRICT_MM_TYPECHECKS?
> I've tested after converting couple of arches, it doesn't
> break STRICT_MM_TYPECHECKS. I intend to keep STRICT_MM_TYPECHECKS working.
> But once the architectures which uses STRICT_MM_TYPECHECKS are converted,
> we don't need STRICT_MM_TYPECHECKS anymore as those checks would be enforced
> by the conversion itself. Thinking out loud:
> 
> Normally:
> typedef pteval_t pte_t;
> 
> In case of STRICT_MM_TYPECHECKS:
> typedef struct { pteval_t pte; } pte_t;
> 
> After introducing type conversions:
> Normally:
> typedef pteval_t pte_t;
> typedef struct {pte_t __pte;} hw_pte_t;
> 
> In case of STRICT_MM_TYPECHECKS:
> typedef struct { pteval_t pte; } pte_t;
> typedef struct { pte_t __pte;} hw_pte_t;
> 
> So after the conversion, it doesn't makes sense to keep STRICT_MM_TYPECHECKS
> around. Please correct me if I'm wrong.

s390 ABI has an unfortunate quirk so that a struct return value
is passed via memory (as opposed to via registers). To avoid that
we turn on STRICT_MM_TYPECHECKS for debug kernels only like this:

#ifdef STRICT_MM_TYPECHECKS

typedef struct { unsigned long pte; } pte_t;

#else /* STRICT_MM_TYPECHECKS */

typedef unsigned long pte_t;

#endif /* STRICT_MM_TYPECHECKS */

So if possible we would like to keep STRICT_MM_TYPECHECKS for performance
reasons.

> 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.
> 
> > 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 am bit lost here, but I think STRICT_MM_TYPECHECKS per se could be
reworked to address the s390 quirk above indeed.

Looking forward to see the patches ;)

> -- 
> Thanks,
> Usama

Thanks!

Re: mm: opaque hardware page-table entry handles

[Alexander Gordeev]

On Fri, Jul 24, 2026 at 08:47:30AM +0200, Alexander Gordeev wrote:
> > > What about unlinked/temporary page tables in memory?
> > I've thought about it multiple times and it is best to represent using hw_p*_t
> > type. Even though they aren't installed or live, but it makes more sense to use
> > hardware type as they may get installed soon. 
> 
> My concern is in the long run the dedicated hw_pte_t APIs may want to do something
> special with a hw_pXX_t pointers: accounting, HW resources allocation, tracking,
> link a shadow, whatever. Some of those might be wrong when applied against a
> temporary copy, even though that copy constitutes a formatted page table in memory.
...
> > The difference between representing stack type with pte_t and unlinked/temporary
> > page table with hw_pte_t is that unlinked/temporary page tables are complete tables
> > and not just some copied value.
...
> Sorry for bringing up the classification question from your original
> message again:
> 
> - "a pointer to a live entry in the hardware page table, or
> - "the pointer points into real page-table memory and that table is complete,
>    whether or not it's linked in yet"
> 
> ...but the semantics of the former still looks to me stronger than one of
> the latter. I am afraid this question is going to pop up time and again.

This is yet another example of why we need to stick to the live entry
requirement hw_pXX_t pointers:

https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@arm.com/

> 1. https://lore.kernel.org/linux-s390/71acca838bd3c5bb690ccb4a36313a889a48f383.1784121418.git.agordeev@linux.ibm.com/

Thanks!