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

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 <[email protected]>
> ---
>  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?

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

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/[email protected]/
2. https://lore.kernel.org/linux-s390/[email protected]/
3. https://lore.kernel.org/linux-s390/[email protected]/

>  #endif
>  }
>  
> -- 
> 2.47.3
>