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

Yeoreum Yun <[email protected]>
Newsgroups dev.linux.lists.loongarch,org.infradead.lists.kvm-riscv,org.infradead.lists.linux-riscv,org.kernel.vger.linux-arch,org.kernel.vger.linux-csky,org.kernel.vger.linux-kernel,org.kernel.vger.linux-m68k,org.kernel.vger.linux-mips,org.kernel.vger.linux-openrisc
Message-ID <[email protected]>
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/[email protected]/

-- 
Sincerely,
Yeoreum Yun
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.