Re: [RFC PATCH 10/34] x86: mm: carve out the generic compile-time folded pgtable case in effective_prot()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/13/26 19:57, Dave Hansen wrote:
> On 7/13/26 08:02, David Hildenbrand (Arm) wrote:
>> It's always been the latter:
>>
>> 	...folding => PUD => PMD => PTE
> 
> This is kinda arguing semantics, and there are different ways to look at
> it. But I'd argue it couldn't *possibly* have always been this way.
> Linux hasn't always had a PUD or a PMD for that matter. The i386 only
> had two levels. PAE support was added later.
> 
> I think the pmd_t came with Alpha support (before my time) and pud_t
> came later IIRC. I'm pretty sure Linux didn't have a pud_t when I first
> started hacking on it circa 2001.

Yes, I'm sure there is some horrible, horrible history to how we came to what we
have today :)

> 
> Second (and again this is my subjective opinion) a pgd_t* has always
> been the "top" or "base" of the page tables. This is why there's an
> mm->pgd and not an mm->pud. We've also talked *forever* about things
> like a "special pgd" for the LDT remap. Or having two pgd pages for KPTI.

Agreed. We always called it pgd, which is just an alias to p4d/pud etc really.

> 
> My point is that the PGD hasn't itself ever been folded. It's the top
> hardware level of the page tables and always has been.

With the history in mind, yes.

Looking at the current state it's more complicated.

Because pgd_present() are really just dummy functions. And this series proposes
to let also pgdp_get() be a dummy function and disallow something like

	set_pgd(pgdp_get())

Which is just asking for trouble. Similar with using pgd_page(pgdp_get()) on

We could get away with catching that case similar to how we catch pgd_offset()
abuse, but I'd rather try get rid of the wrapper functions set_pgd() /
pgd_page() entirely.

But if we feel like that is too much, we can look into that direction.

> 
> I really do think this series is changing things, not keeping them the same.

Looking at it from that angle, I tend do agree: it further moves into the
direction that actually the p4d_present() carries value, and the previous
pgd_present() is just a dummy.

I can see that some more work is required to untangle the mess we already have.

I don't know why pgd_present() was made a dummy function and not p4d_present(),
but I'm sure there is a good reason to it. Changing that now ... omg.

-- 
Cheers,

David