From: Pingfan Liu <kernelfans@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: Linux-MM <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: Fri, 17 Jan 2020 14:18:40 +0800 [thread overview]
Message-ID: <CAFgQCTs2i-4XtqJQfmsXVUGxMe+=PzQCwkbAACMw7gj3=qxqtQ@mail.gmail.com> (raw)
In-Reply-To: <97ab281f-d038-d40c-648a-e0085a906dcf@redhat.com>
On Thu, Jan 16, 2020 at 4:06 PM David Hildenbrand <david@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
>
prev parent reply other threads:[~2020-01-17 6:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 3:01 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
2020-01-16 8:57 ` David Hildenbrand
2020-01-17 6:20 ` Pingfan Liu
2020-01-17 6:18 ` Pingfan Liu [this message]
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='CAFgQCTs2i-4XtqJQfmsXVUGxMe+=PzQCwkbAACMw7gj3=qxqtQ@mail.gmail.com' \
--to=kernelfans@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=k-hagio@ab.jp.nec.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox