Re: [PATCH v3 02/16] mm: introduce leaf entry type and use to simplify leaf entry logic

Zi Yan
2025-11-11T16:26:13Z

On 11 Nov 2025, at 8:06, David Hildenbrand (Red Hat) wrote:

> On 11.11.25 04:25, Zi Yan wrote:
>> On 10 Nov 2025, at 17:21, Lorenzo Stoakes wrote:
>>
>>> The kernel maintains leaf page table entries which contain either:
>>>
>>> - Nothing ('none' entries)
>>> - Present entries (that is stuff the hardware can navigate without fault)
>>
>> This is not true for:
>>
>> 1. pXX_protnone(), where _PAGE_PROTNONE flag also means pXX_present() is
>> true, but hardware would still trigger a fault.
>> 2. pmd_present() where _PAGE_PSE also means a present PMD (see the comment
>> in pmd_present()).
>
> I'll note that pte_present/pmd_present etc is always about "soft-present".
>
> For example, if the hardware does not have a hw-managed access bit, doing a pte_mkyoung() would also clear the hw-valid/hw-present bit because we have to catch any next access done by hardware.
>
> [fun fact: some hardware has an invalid bit instead of a valid/present bit :) IIRC s390x falls into that category]
>
> Similar things happen on ordinary PROT_NONE of course (independent of pte_protnone).
>
> A better description might be "there is a page/pfn mapped here, but it might not be accessible by the CPU right now".
>
> We have device-exclusive/device-private nonswap (before this series) entries that fall into the same category, unfortunately ("there is something mapped there that is not accessible by the CPU")

I agree. I am fine with the categorization using pte_none(), pte_present(),
and softleaf. It is “hardware can navigate without fault” that causes
confusion. Removing this comment would work for me, since people can look
at the definition of pXX_present() for further clarification.

Best Regards,
Yan, Zi