Re: [PATCH 6/9] mm: convert PTE table entry to pte

[Muhammad Usama Anjum]

On 07/08/2026 7:58 am, Alexander Gordeev wrote:
> On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:
>> The non-MMU stub receives hw_pte_t but returns a logical pte_t
>> value. Convert the stored entry through __pte_from_hw() before
>> returning.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@xxxxxxx>
>> ---
>>  include/linux/hugetlb.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index bc0b9c65aa1d0..9e8b391aa4bc9 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -1283,7 +1283,7 @@ static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>>  #ifdef CONFIG_MMU
>>  	return ptep_get(ptep);
>>  #else
>> -	return *ptep;
>> +	return __pte_from_hw(*ptep);
> 
> But this is a direct dereferencing, which breaks the whole point, isn't it?
Yes, this is particular line is for non MMU. In this case, CONIFG_ARCH_HAS_HW_PTE
would never be defined. Hence hw_pte_t is just pte_t and direct dereference is
allowed. I'd thought a lot about it; is better to leave direct dereference here
or use some helper. Then used __pte_from_hw() was already being used in generic
ptep_get().

There are only two users of __pte_from_hw() at this time. 

> 
> What about introducing something like pte_t ptep_get_sw(hw_pte_t *ptep)
> to be used in exactly situations like this? With that the semantics of
> hw_pte_t pointers becomes straightforward and closes the still ongoing
> "storage vs lifetime" discussion:
> 
> hw_pte_t*     points to HW-formatted page table entries
> 
> ptep_get()    is used to obtain HW-linked/attached entries, and may wire
>               extra code like [1] or [2]
> 
> ptep_get_sw() is used to obtain HW-unlinked/unattached entries and in
>               most cases is just a direct dereference
ptep_get_sw() or ptep_get_deref() is better name here?

I thought __pte_from_hw() is ugly enough that if someone tries to use it
wrongly, it'll be noticed pretty easily. I'm fine with any other name.

> 
> The caller should always know whether the entry is attached or not, so
> confusions like [3] are avoided.
> 
> 1. https://lore.kernel.org/linux-mm/20260526-kpkeys-v8-21-eaaacdacc67c@xxxxxxx/
> 2. https://lore.kernel.org/linux-s390/650903a4-0dd9-4e6b-9d4b-3c32c5657236-agordeev@xxxxxxxxxxxxx/
> 3. https://lore.kernel.org/linux-s390/b44e071d-7c9d-4e7e-a84d-4af3499a5a05@xxxxxxx/
> 
>>  #endif
>>  }
>>  
>> -- 
>> 2.47.3
>>

-- 
Thanks,
Usama