> On Jan 15, 2020, at 10:01 PM, Pingfan Liu <kernelfans@xxxxxxxxx> wrote: > > When fully deactivated, it is meaningless to keep the value of a section's > mem_map. And its mem_map will be reassigned during re-added. > > Beside this, it breaks the user space tool "makedumpfile", which makes > assumption that a hot-removed section having mem_map as NULL. Well, tools like makedumpfile and the crash utility always has to copy with low kernel implementation details changes like this. Why is it different this time? > > The bug can be reproduced on IBM POWERVM by "drmgr -c mem -r -q 5" , > trigger a crash, and save vmcore by makedumpfile > > Signed-off-by: Pingfan Liu <kernelfans@xxxxxxxxx> > To: linux-mm@xxxxxxxxx > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: David Hildenbrand <david@xxxxxxxxxx> > Cc: Dan Williams <dan.j.williams@xxxxxxxxx> > Cc: Oscar Salvador <osalvador@xxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxxxxx> > Cc: kexec@xxxxxxxxxxxxxxxxxxx > Cc: Kazuhito Hagio <k-hagio@xxxxxxxxxxxxx> > --- > mm/sparse.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/sparse.c b/mm/sparse.c > index 3822ecb..fddac80 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c > @@ -789,7 +789,7 @@ static void section_deactivate(unsigned long pfn, unsigned long nr_pages, > ms->usage = NULL; > } > memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr); > - ms->section_mem_map = sparse_encode_mem_map(NULL, section_nr); > + ms->section_mem_map = NULL; > } > > if (section_is_early && memmap) > -- > 2.7.5 > >
