On Thu, Jan 16, 2020 at 4:06 PM David Hildenbrand <david@xxxxxxxxxx> 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 >
