Re: [PATCH 6/9] mm: convert PTE table entry to pte
Alexander Gordeev <[email protected]>
| Newsgroups | gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.ports.parisc,gmane.comp.emulators.xen.devel,gmane.linux.kernel.mm,gmane.linux.file-systems,gmane.linux.kernel.cross-arch,gmane.linux.kernel.bpf,gmane.linux.kernel.perf.user |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 07, 2026 at 05:26:04PM +0100, Muhammad Usama Anjum wrote: > 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(). But in case CONIFG_ARCH_HAS_HW_PTE=n __pte_from_hw() is still gets called. That looks inconsistent to me. Why not just call ptep_deref() (see below)? > 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? ptep_deref() would be it. Do you agree to the suggested API requirements? > 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 name may be not perfect, but it is the way it is used above looks wrong to me. > > 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 > >> } Thanks! > -- > Thanks, > Usama >