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

[Yeoreum Yun]

On Mon, Jul 13, 2026 at 07:19:47AM -0700, Dave Hansen wrote:
> On 7/13/26 06:55, Yeoreum Yun wrote:
> > We want to change how pXdp_get() works with generic compile-time folded
> > page tables. To prepare for that, rework effective_prot() to ignore any
> > folded page tables entries, as it will unconditionally get called by
> > ptdump core with pXd_val(pXdp_get()), and we really should be ignoring
> > that value for folded entries.
> > 
> > For this, identify the first real page-table level and
> > update effective_prot only when the current entry is not folded.
> 
> Nit: could you please clean up the "we's" and move over to imperative
> voice for the series? We're picky about it on the x86 side, but I do
> think it's generally a good preferred practice across the kernel.

Okay... let us reparse in the next version.

> 
> Also I really do think this made the code worse. effective_prot() is a
> pretty tidy function. This change more than doubles the size and is also
> basically the same block copied and pasted twice.
> 
> Further, this does seem like it will stop filling out some of the
> st->prot_levels[] entries. That seems like it might break things. It
> definitely needs to be covered in the changelog.
> 
> So, in the end, I'm not 100% sure what this is doing. Is it "optimizing"
> the ptdump code? Or is it preemptively fixing code that will soon be
> throwing a compile error?

As a part of fixing code for chaning of pXdp_get() which can return
a dummy value for the folded table case since current pXdp_get() mostly
fallback to READ_ONCE(), it generates a meaningless code for it [1].

And this code change doesn't seems to miss anything since it skips
setting of st->prot_levels[] for "folded pagtable" only.
so It doesn't seem to break anything.

In the perspective of effective_prot() change only. this optimization
wouldn't be observed since it would be applied at the upper layer in
ptdump.c But I think this is required to handle a dummy entry properly.


Link: [1] https://lore.kernel.org/all/0019d675-ce3d-4a5c-89ed-f126c45145c9@kernel.org/

-- 
Sincerely,
Yeoreum Yun