[PATCH 01/49] mm/sparse: fix vmemmap accounting imbalance on memory hotplug error

Mike Rapoport rppt at kernel.org
Tue Apr 14 03:20:07 AEST 2026


On Mon, Apr 13, 2026 at 10:16:20PM +0800, Muchun Song wrote:
> >> +++ b/mm/sparse-vmemmap.c
> >> @@ -656,7 +656,13 @@ static struct page * __meminit populate_section_memmap(unsigned long pfn,
> >>       unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
> >>       struct dev_pagemap *pgmap)
> >> {
> >> -    return __populate_section_memmap(pfn, nr_pages, nid, altmap, pgmap);
> >> +    struct page *p = __populate_section_memmap(pfn, nr_pages, nid, altmap,
> >> +                           pgmap);
> >> +
> >> +    if (p)
> >> +        memmap_pages_add(DIV_ROUND_UP(nr_pages * sizeof(struct page), PAGE_SIZE));
> > 
> > We don’t increase the counter on failure, then
> > 
> >> +
> >> +    return p;
> >> }
> >> 
> >> static void depopulate_section_memmap(unsigned long pfn, unsigned long nr_pages,
> >> @@ -826,7 +832,6 @@ static struct page * __meminit section_activate(int nid, unsigned long pfn,
> >>       section_deactivate(pfn, nr_pages, altmap);
> > 
> > here section_deactivate() is called, which decrease the counter unconditionally,
> > the issue still exists. We didn't fix anything.

You are right, I missed it :/

> >>       return ERR_PTR(-ENOMEM);
> >>   }
> >> -    memmap_pages_add(DIV_ROUND_UP(nr_pages * sizeof(struct page), PAGE_SIZE));
> >> 
> >>   return memmap;
> >> }
> >> 
> >> 
> >> Then we'll better follow "all or nothing" principle and won't have
> >> exceptional cases in section_deactivate().
> 
> To follow  "all or nothing" principle here, I think we should not call
> section_deactivate() to do the cleanup in section_activate().
> 
> After all, if section_activate() didn't succeed, how can we use
> section_deactivate() to release the resources? What do you think?

Yeah, if we could pull "upopulate" from section_deactivate() that would be
great.
 
> Thanks.

-- 
Sincerely yours,
Mike.


More information about the Linuxppc-dev mailing list