On Thu, Jan 16, 2020 at 4:06 PM David Hildenbrand <da...@redhat.com> wrote:
>
> On 16.01.20 04:01, Pingfan Liu 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.
> >
> > The bug can be reproduced on IBM POWERVM by "drmgr -c mem -r -q 5" ,
> > trigger a crash, and save vmcore by makedumpfile
>
> Are you using an up-to-date makedumfile and did kdump.service properly
> get reloaded on the udev events? I remember that this works.
I tried to get a machine and double-check it. The latest devel branch
of makedumpfile can not work.
>
> makedumpfile will not dump memory sections that a) are not marked
> offline (SECTION_IS_ONLINE) - after offlining b) are not part of an
> iomem resource - after memory unplug.
I think the current implementation of makedumpfile should improve the
handling process.

And my primary argument for this patch is a pattern like alloc/free.
And when fully deactivated, it is meaningless to keep the section
start pfn info
>
>
> The current code makes sure that sparse_decode_mem_map() will return NULL.
Do you mean the code in makedumpfile?  If yes, it can. But
makedumpfile related code has some bug, and should be improved to
utilize this function.

Thanks,
Pingfan
>
> --
> Thanks,
>
> David / dhildenb
>

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to