From: Baoquan He <bhe@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Pingfan Liu <kernelfans@gmail.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@kernel.org>,
kexec@lists.infradead.org, Kazuhito Hagio <k-hagio@ab.jp.nec.com>
Subject: Re: [PATCH] mm/sparse: reset section's mem_map when fully deactivated
Date: Thu, 16 Jan 2020 16:24:51 +0800 [thread overview]
Message-ID: <20200116082451.GC26758@MiWiFi-R3L-srv> (raw)
In-Reply-To: <6cfd834a-72cc-656a-3954-40b37db5a66f@redhat.com>
On 01/16/20 at 09:14am, David Hildenbrand wrote:
> On 16.01.20 09:06, David Hildenbrand 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.
> >
> > 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.
Makedumpfile seems to only check SECTION_MARKED_PRESENT. Then the NULL
memmap will fail vmcore dumping, I guess.
> >
> >
> > The current code makes sure that sparse_decode_mem_map() will return NULL.
> >
>
> ... but it's only used at this very place. I think we should add a
> Fixes: tag, although this might be fixed as well in makedumpfile (so
> people are aware that patch broke something)
Agree, it's worth fixing it too in makedumpfile side to enhance.
next prev parent reply other threads:[~2020-01-16 8:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 3:01 [PATCH] mm/sparse: reset section's mem_map when fully deactivated Pingfan Liu
2020-01-16 3:18 ` Qian Cai
2020-01-16 3:34 ` Pingfan Liu
2020-01-16 7:50 ` Michal Hocko
2020-01-17 6:22 ` Pingfan Liu
2020-01-17 7:14 ` Dan Williams
2020-01-17 7:47 ` Michal Hocko
2020-01-17 9:49 ` Pingfan Liu
2020-01-17 9:52 ` David Hildenbrand
2020-01-20 2:31 ` Pingfan Liu
2020-01-16 8:06 ` David Hildenbrand
2020-01-16 8:14 ` David Hildenbrand
2020-01-16 8:24 ` Baoquan He [this message]
2020-01-16 8:57 ` David Hildenbrand
2020-01-17 6:20 ` Pingfan Liu
2020-01-17 6:18 ` Pingfan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200116082451.GC26758@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=k-hagio@ab.jp.nec.com \
--cc=kernelfans@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.