From: Dan Williams <dan.j.williams@intel.com>
To: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Cc: Baoquan He <bhe@redhat.com>,
"vgoyal@redhat.com" <vgoyal@redhat.com>,
"dyoung@redhat.com" <dyoung@redhat.com>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"dave.jiang@intel.com" <dave.jiang@intel.com>,
"horms@verge.net.au" <horms@verge.net.au>,
"k-hagio-ab@nec.com" <k-hagio-ab@nec.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
"yangx.jy@fujitsu.com" <yangx.jy@fujitsu.com>,
"ruansy.fnst@fujitsu.com" <ruansy.fnst@fujitsu.com>
Subject: RE: [RFC][nvdimm][crash] pmem memmap dump support
Date: Thu, 16 Mar 2023 23:12:58 -0700 [thread overview]
Message-ID: <641404ea806dc_a52e2949@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <3c752fc2-b6a0-2975-ffec-dba3edcf4155@fujitsu.com>
lizhijian@fujitsu.com wrote:
[..]
> Case D: unsupported && need your input To support this situation, the
> makedumpfile needs to know the location of metadata for each pmem
> namespace and the address and size of metadata in the pmem [start,
> end)
My first reaction is that you should copy what the ndctl utility does
when it needs to manipulate or interrogate the metadata space.
For example, see namespace_rw_infoblock():
https://github.com/pmem/ndctl/blob/main/ndctl/namespace.c#L2022
That facility uses the force_raw attribute
("/sys/bus/nd/devices/namespaceX.Y/force_raw") to arrange for the
namespace to initalize without considering any pre-existing metdata
*and* without overwriting it. In that mode makedumpfile can walk the
namespaces and retrieve the metadata written by the previous kernel.
The module to block to allow makedumpfile to access the namespace in raw
mode is the nd_pmem module, or if it is builtin the
nd_pmem_driver_init() initcall.
next prev parent reply other threads:[~2023-03-17 6:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 6:24 lizhijian
2023-02-28 14:03 ` Baoquan He
2023-03-01 6:27 ` lizhijian
2023-03-01 8:17 ` Baoquan He
2023-03-03 2:27 ` lizhijian
2023-03-03 9:21 ` Baoquan He
2023-03-07 2:05 ` HAGIO KAZUHITO(萩尾 一仁)
2023-03-07 2:49 ` lizhijian
2023-03-07 8:31 ` HAGIO KAZUHITO(萩尾 一仁)
2023-03-17 6:12 ` Dan Williams [this message]
2023-03-17 7:30 ` lizhijian
2023-03-17 15:19 ` Dan Williams
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=641404ea806dc_a52e2949@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dave.jiang@intel.com \
--cc=dyoung@redhat.com \
--cc=horms@verge.net.au \
--cc=k-hagio-ab@nec.com \
--cc=kexec@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=lizhijian@fujitsu.com \
--cc=nvdimm@lists.linux.dev \
--cc=ruansy.fnst@fujitsu.com \
--cc=vgoyal@redhat.com \
--cc=vishal.l.verma@intel.com \
--cc=y-goto@fujitsu.com \
--cc=yangx.jy@fujitsu.com \
/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