Re: [PATCH 1/1] mm/huge_memory: fix pgtable withdrawal for huge zero PMDs

[Kiryl Shutsemau <kas@kernel.org>]

On Tue, Sep 15, 2026 at 09:43:15PM +0800, Lance Yang wrote:
> 
> 
> On 2026/9/15 02:19, Andrew Morton wrote:
> > On Mon, 14 Sep 2026 16:29:00 +0200 "David Hildenbrand (Arm)" <david@kernel.org> wrote:
> > 
> > > On 9/14/26 12:59, Kiryl Shutsemau wrote:
> > > > On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
> > > > > 
> > > > > On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
> > > > > > 
> > > > > > 
> > > > > > That's the sort of thing we'd prefer to avoid.
> > > > > > 
> > > > > > 
> > > > > > How real is this?  Is there a reported-by:?  Do you have a reproducer?
> > > > > 
> > > > > Yes, I reproduced it on x86 with a small test module. It sets
> > > > > VM_MIXEDMAP | VM_HUGEPAGE and calls vmf_insert_pfn_pmd() with
> > > > > huge_zero_pfn, without touching the page tables directly. A full-PMD
> > > > > munmap() crashes before the split series[1] as well.
> > > > 
> > > > Ah. So there's no real bug upstream, right?
> > > 
> > > Matches my understanding.
> > 
> > Thanks.  I'll remove cc:stable, move this into mm-unstable as a
> > next-merge-window thing.
> 
> Sounds good to me, thanks, Andrew!
> 
> Kiryl, David, would you prefer the validation for raw-PFN mappings
> of the huge zero page as a separate follow-up, or should that
> validation replace this patch? wdyt

I think this patch can be useful for graceful recovery if we somehow ended up
with a zero page in a mapping where we shouldn't have one.

A separate patch with validation would be great.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov