Re: [PATCH] x86/mm/pat: allocate split page tables as kernel page tables

On Tue, Jul 21, 2026 at 10:58:50AM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Jul 21, 2026 at 02:45:43AM -0700, Vishal Moola wrote:
> > >
> > > Well some kernel page tables are still allocated without ctor (early allocated
> > > direct map for isntance), and if you did pagetable_dtor_free() it
> > > unconditionally calls pagetable_dtor().

TBH, I cannot think of a scenario when page tables allocated at boot would
be collapsed. But surely, checking the page type is safer just in case.

> > > The ptlock_free() and __folio_clear_pgtable() there would be harmelss (no locks
> > > assigned for kernel page table, and if PG_table never set clearing it is a noop)
> > > but the lruvec_stat_sub_folio() would cause an unbalanced decrement of
> > > nr_page_table_pages.
> >
> > Gotcha, thanks for the explanation :)
> 
> No worries, this is subtle stuff with lots of weird gotchas and stuff we need to
> improve... I seem to have fallen down an unexpected rabbit hole with these fixes
> :)
> 
> >
> > > It sucks, but until everything is updated to call the ctor we have to do it this
> > > way :>)
> >
> > Yeah that makes sense. Although I'd rather see the condition as:
> > if(PageTable(ptdesc_page(...)))
> >
> > We really shouldn't be calling ptdesc_folio() anywhere anymore.
> 
> I think better for a follow up since the code already uses ptdesc all over the
> place (fundamental to the approach really, keeping a list of page tables etc.)
> and this is a fix that needs backporting.

I agree with Vishal that it's better to use page type rather than folio
type. And it's the same for backporting ;-) 
 
> Cheers, Lorenzo

-- 
Sincerely yours,
Mike.