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 <[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? 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/[email protected]/ > 2. > https://lore.kernel.org/linux-s390/[email protected]/ > 3. > https://lore.kernel.org/linux-s390/[email protected]/ > >> #endif >> } >> >> -- >> 2.47.3 >> -- Thanks, Usama
