On Fri, Jan 24, 2020 at 2:49 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> On Thu 23-01-20 19:10:47, Andrew Morton wrote:
> > On Mon, 20 Jan 2020 08:29:39 +0100 Michal Hocko <mhocko@xxxxxxxx> wrote:
> >
> > > On Mon 20-01-20 10:33:14, Pingfan Liu wrote:
> > > > After commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug"),
> > > > when a mem section is fully deactivated, section_mem_map still records the
> > > > section's start pfn, which is not used any more and will be reassigned
> > > > during re-added.
> > > >
> > > > In analogy with alloc/free pattern, it is better to clear all fields of
> > > > section_mem_map.
> > > >
> > > > Beside this, it breaks the user space tool "makedumpfile" [1], which makes
> > > > assumption that a hot-removed section has mem_map as NULL, instead of
> > > > checking directly against SECTION_MARKED_PRESENT bit. (makedumpfile will be
> > > > better to change the assumption, and need a patch)
> > > >
> > > > The bug can be reproduced on IBM POWERVM by "drmgr -c mem -r -q 5" ,
> > > > trigger a crash, and save vmcore by makedumpfile
> > >
> > > While makedumpfile lives very closely to the kernel and occasional
> > > breakage is to be expected I still believe that Fixes: ba72b4c8cf60
> > > is due.
> >
> > But not a cc:stable?
>
> Well, I wouldn't say this is really critical. makedumpfile will get its
> fix... But if people think it would be useful in stable I won't oppose.
Yes, I think this patch is no more than a prototype improvement, and
makedumpfile has better to get its fix.
And I have sent a patch to kexec-list for it.
(http://lists.infradead.org/pipermail/kexec/2020-January/024406.html)
Thanks,
Pingfan
