Re: [RFC V1 PATCH mm-hotfixes 2/3] x86/mm: define p*d_populate_kernel() and top-level page table sync

[Harry Yoo <harry.yoo@oracle.com>]

On Fri, Jul 11, 2025 at 01:02:08PM +0900, Harry Yoo wrote:
> On Thu, Jul 10, 2025 at 05:27:36PM +0900, Harry Yoo wrote:
> > On Wed, Jul 09, 2025 at 02:13:59PM -0700, Andrew Morton wrote:
> > > On Wed,  9 Jul 2025 22:16:56 +0900 Harry Yoo <harry.yoo@oracle.com> wrote:
> > > 
> > > > Fixes: 4917f55b4ef9 ("mm/sparse-vmemmap: improve memory savings for compound devmaps")
> > > > Fixes: faf1c0008a33 ("x86/vmemmap: optimize for consecutive sections in partial populated PMDs")
> > > 
> > > Fortunately both of these appeared in 6.9-rc7, which minimizes the
> > > problem with having more than one Fixes:.
> > > 
> > > But still, the Fixes: is a pointer telling -stable maintainers where in
> > > the kernel history we want them to insert the patch(es).  Giving them
> > > multiple insertions points is confusing!  Can we narrow this down
> > > to a single Fixes:?
> > 
> > If I had to choose only one I think it should be 4917f55b4ef9,
> > since faf1c0008a33 is not yet known to be triggered without enlarging
> > struct page (and once it's backported it fixes both of them).
> 
> On second look, faf1c0008a33 is introduced in v5.13-rc1 and
> 4917f55b4ef9 is introduced in v5.19-rc1.
> 
> I'll go with Fixes: faf1c0008a33 because it's introduced earlier.

Uh, on third look Fixes: faf1c0008a33 is incorrect :/
It's Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges").

This is the commit that started initializing unused vmemmap with
PAGE_UNUSED, and can lead to bugs when current task's mm is not init_mm
because as accessing vmemmap before sync_global_pgds().

-- 
Cheers,
Harry / Hyeonggon