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

On 07/08/2026 7:58 am, Alexander Gordeev wrote:

On Thu, Aug 06, 2026 at 09:38:44AM +0100, Muhammad Usama Anjum wrote:

quoted

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 <redacted>
---
 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@arm.com/ (local)
2. https://lore.kernel.org/linux-s390/650903a4-0dd9-4e6b-9d4b-3c32c5657236-agordeev@linux.ibm.com/ (local)
3. https://lore.kernel.org/linux-s390/b44e071d-7c9d-4e7e-a84d-4af3499a5a05@arm.com/ (local)

quoted

 #endif
 }
 
-- 
2.47.3

-- 
Thanks,
Usama