Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2023826rwd; Fri, 2 Jun 2023 03:52:46 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7MHdYfrUkx5kwvRII0erzBq+UkUtnFwElv1xX21Hwk5nFq/isIhPVmuM9pAuT8NCUfobSi X-Received: by 2002:aca:2201:0:b0:394:39dc:a4b0 with SMTP id b1-20020aca2201000000b0039439dca4b0mr2080411oic.52.1685703166353; Fri, 02 Jun 2023 03:52:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685703166; cv=none; d=google.com; s=arc-20160816; b=m3EkhW8YbfHkQJSxEcb0NR+ZqRLE5AoaAWjGRzsGIus+E56xBXfV0TT5ACxTU82HNl 1O6cEvj/V3pz8mX/Fyn1+0vqvnv/Lmk74sRk2eFRQd6346JU+ipFXbWolN3912w9X2zw UrOB8DznjBnD6Tb8vn0Lsk+enALI3Z/Gt4CWOueuDBeSOnZu3vokTK4ZC4RSZwOTowFV iMLOo9ZkBUcmdssF2VUkK7YU585k79QToasOhP1JQIE3lSCeAYNjLTL9qy0VQ0IE+tG1 EwDe03rACigdXSXe+VYeL8KOuvTOxfPxlA0Z2rkux3LY3/AVyZgDoICgsB9BVBuxInPM ST/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=EvadMyZDLE7T0UF1/UK8rxZ9pHXrZ+s4tfDMGUSPQGg=; b=JdkINDlfEoyu92vwxfZNNCHw0N0dv5L8kvzwFBpj6wHC+XIQ79SYCmUjtYAGbc4rHl ngIRm651rpCkpIkA/su+S42ZXf+E1Vnt22KDdIQHG5OxOSJw9W9PmC9KVGGyKfAB2i0k JmUujXd+0q1qVYJlRDWAxF4Yppjx3POMnd9w7dfZlDexCNcY8TWgO27oqIo3WRgYeMUz prjalT+39lNUFd+3nGFe28Q5/wiuK596K7yunBayFyN/stKYOA6tG2l56tJEAwscuT6W AVyeuMu5yu8mq8s7dZmQRgY4yKbdDnUpoLjVmp+ezzoGtMsiUv6VgonPDgOn0WRdZCur JIyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=fujitsu.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a18-20020aa78e92000000b0063b68fa0807si550516pfr.263.2023.06.02.03.52.34; Fri, 02 Jun 2023 03:52:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=fujitsu.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235466AbjFBKfm (ORCPT + 99 others); Fri, 2 Jun 2023 06:35:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235941AbjFBKfI (ORCPT ); Fri, 2 Jun 2023 06:35:08 -0400 Received: from esa11.hc1455-7.c3s2.iphmx.com (esa11.hc1455-7.c3s2.iphmx.com [207.54.90.137]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF5B3198E for ; Fri, 2 Jun 2023 03:34:05 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6600,9927,10728"; a="98600091" X-IronPort-AV: E=Sophos;i="6.00,212,1681138800"; d="scan'208";a="98600091" Received: from unknown (HELO oym-r3.gw.nic.fujitsu.com) ([210.162.30.91]) by esa11.hc1455-7.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jun 2023 19:27:09 +0900 Received: from oym-m4.gw.nic.fujitsu.com (oym-nat-oym-m4.gw.nic.fujitsu.com [192.168.87.61]) by oym-r3.gw.nic.fujitsu.com (Postfix) with ESMTP id 0A2E1CA1E8 for ; Fri, 2 Jun 2023 19:27:06 +0900 (JST) Received: from kws-ab4.gw.nic.fujitsu.com (kws-ab4.gw.nic.fujitsu.com [192.51.206.22]) by oym-m4.gw.nic.fujitsu.com (Postfix) with ESMTP id 36982D616D for ; Fri, 2 Jun 2023 19:27:05 +0900 (JST) Received: from localhost.localdomain (unknown [10.167.234.230]) by kws-ab4.gw.nic.fujitsu.com (Postfix) with ESMTP id 1DB03E4AAF; Fri, 2 Jun 2023 19:27:04 +0900 (JST) From: Li Zhijian To: kexec@lists.infradead.org, nvdimm@lists.linux.dev Cc: linux-kernel@vger.kernel.org, dan.j.williams@intel.com, bhe@redhat.com, ruansy.fnst@fujitsu.com, y-goto@fujitsu.com, yangx.jy@fujitsu.com, Li Zhijian , Vishal Verma , Dave Jiang , Ira Weiny Subject: [RFC PATCH v3 1/3] nvdimm: set force_raw=1 in kdump kernel Date: Fri, 2 Jun 2023 18:26:50 +0800 Message-Id: <20230602102656.131654-2-lizhijian@fujitsu.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20230602102656.131654-1-lizhijian@fujitsu.com> References: <20230602102656.131654-1-lizhijian@fujitsu.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSS-9.1.0.1417-9.0.0.1002-27666.006 X-TM-AS-User-Approved-Sender: Yes X-TMASE-Version: IMSS-9.1.0.1417-9.0.1002-27666.006 X-TMASE-Result: 10-0.974000-10.000000 X-TMASE-MatchedRID: t1Iw0ML99//7w6uw5pqYnoOlbll4OMtk9LMB0hXFSeg6Zx3YUNQTG+Wh NKYuM7eN4QRvjxz49tHS7j6TEIEt1D3TQfUpAv1sPkILbTHNp5vYUDvAr2Y/17fYIuZsOQ0sOXB 2cqV0mCIre4xpX839SFAz81vtOOYiZ4F2TwmYmEDum6Nvy6t3NlK6+0HOVoSoWAuSz3ewb22AI+ pLfk3sByL637QCIVpi8vc3EUpCmrV9Y/vlKk76U9splnBzc8xMTFQnI+epPIaRo95rkBSGU6PFj JEFr+olwXCBO/GKkVqOhzOa6g8KrW2CLRXivi3wNhkKY/nNBRst5qYpMkBetMsgyaJj+IZ28rnl FWxtjwA8cpbtw5mTmssX0GOwKpO0i+7bNO++4Qw50ytg9FCbQRXBt/mUREyAj/ZFF9Wfm7hNy7p pG0IjcFQqk0j7vLVUewMSBDreIdk= X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 we choose the 3rd one because the kdump application in this RFC relies on some /sys interfaces exported by libnvdimm and nd_pmem etc. CC: Dan Williams CC: Vishal Verma CC: Dave Jiang CC: Ira Weiny CC: nvdimm@lists.linux.dev Signed-off-by: Li Zhijian --- V3: new patch --- 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 c60ec0b373c5..2e59be8b9c78 100644 --- a/drivers/nvdimm/namespace_devs.c +++ b/drivers/nvdimm/namespace_devs.c @@ -8,6 +8,7 @@ #include #include #include +#include #include "nd-core.h" #include "pmem.h" #include "pfn.h" @@ -1504,6 +1505,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