linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Li Zhijian <lizhijian@fujitsu.com>
To: linux-kernel@vger.kernel.org
Cc: y-goto@fujitsu.com, Alison Schofield <alison.schofield@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Baoquan He <bhe@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	hpa@zytor.com, Ingo Molnar <mingo@redhat.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vishal Verma <vishal.l.verma@intel.com>,
	linux-cxl@vger.kernel.org, linux-mm@kvack.org,
	nvdimm@lists.linux.dev, x86@kernel.org,
	kexec@lists.infradead.org, Li Zhijian <lizhijian@fujitsu.com>
Subject: [PATCH v3 7/7] nvdimm: set force_raw=1 in kdump kernel
Date: Wed,  6 Mar 2024 18:28:46 +0800	[thread overview]
Message-ID: <20240306102846.1020868-8-lizhijian@fujitsu.com> (raw)
In-Reply-To: <20240306102846.1020868-1-lizhijian@fujitsu.com>

The virtually mapped memory map allows storing struct page objects for
persistent memory devices in pre-allocated storage on those devices.
These 'struct page objects' on devices are also known as metadata.

During libnvdimm/nd_pmem are loading, the previous metadata will
be re-constructed to fit the current running kernel. For kdump purpose,
these metadata should not be touched until the dumping is done so that
the metadata is identical.

To achieve this, we have some options
1. Don't provide libnvdimm driver in kdump kernel rootfs/initramfs
2. Disable libnvdimm driver by specific comline parameters:
   (initcall_blacklist=libnvdimm_init libnvdimm.blacklist=1 rd.driver.blacklist=libnvdimm)
3. Enforce force_raw=1 for nvdimm namespace, because when force_raw=1,
   metadata will not be re-constructed again. This may also result in
   the pmem doesn't work before a few extra configurations.

Here apply the 3rd option.

CC: Dan Williams <dan.j.williams@intel.com>
CC: Vishal Verma <vishal.l.verma@intel.com>
CC: Dave Jiang <dave.jiang@intel.com>
CC: Ira Weiny <ira.weiny@intel.com>
CC: nvdimm@lists.linux.dev
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
 drivers/nvdimm/namespace_devs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index d6d558f94d6b..04f855c7f0b1 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -9,6 +9,7 @@
 #include <linux/slab.h>
 #include <linux/list.h>
 #include <linux/nd.h>
+#include <linux/crash_dump.h>
 #include "nd-core.h"
 #include "pmem.h"
 #include "pfn.h"
@@ -1513,6 +1514,8 @@ struct nd_namespace_common *nvdimm_namespace_common_probe(struct device *dev)
 			return ERR_PTR(-ENODEV);
 	}
 
+	if (is_kdump_kernel())
+		ndns->force_raw = true;
 	return ndns;
 }
 EXPORT_SYMBOL(nvdimm_namespace_common_probe);
-- 
2.29.2



  parent reply	other threads:[~2024-03-06 10:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 10:28 [RFC PATCH v3 0/7] device backed vmemmap crash dump support Li Zhijian
2024-03-06 10:28 ` [PATCH v3 1/7] mm: memremap: register/unregister altmap region to a separate resource Li Zhijian
2024-03-06 10:28 ` [PATCH v3 2/7] mm: memremap: add pgmap_parent_resource() helper Li Zhijian
2024-03-06 10:28 ` [PATCH v3 3/7] nvdimm: pmem: assign a parent resource for vmemmap region for the fsdax Li Zhijian
2024-03-07  8:07   ` kernel test robot
2024-03-07 11:08   ` kernel test robot
2024-03-06 10:28 ` [PATCH v3 4/7] dax: pmem: assign a parent resource for vmemmap region for the devdax Li Zhijian
2024-03-06 10:28 ` [PATCH v3 5/7] resource: Introduce walk device_backed_vmemmap res() helper Li Zhijian
2024-03-06 10:28 ` [PATCH v3 6/7] x86/crash: make device backed vmemmap dumpable for kexec_file_load Li Zhijian
2024-03-06 10:28 ` Li Zhijian [this message]
2024-03-21  5:40 ` [RFC PATCH v3 0/7] device backed vmemmap crash dump support Zhijian Li (Fujitsu)
2024-03-21  6:17   ` Baoquan He
2024-03-21  6:57     ` Zhijian Li (Fujitsu)
2024-04-19  2:05   ` Zhijian Li (Fujitsu)

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=20240306102846.1020868-8-lizhijian@fujitsu.com \
    --to=lizhijian@fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=alison.schofield@intel.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=ira.weiny@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=tglx@linutronix.de \
    --cc=vishal.l.verma@intel.com \
    --cc=x86@kernel.org \
    --cc=y-goto@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;
as well as URLs for NNTP newsgroup(s).