From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B2CDC64EC7 for ; Wed, 1 Mar 2023 08:17:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07DFE6B0073; Wed, 1 Mar 2023 03:17:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 02C126B0075; Wed, 1 Mar 2023 03:17:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E368C6B007B; Wed, 1 Mar 2023 03:17:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id D4E2D6B0073 for ; Wed, 1 Mar 2023 03:17:38 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 94123C13B0 for ; Wed, 1 Mar 2023 08:17:38 +0000 (UTC) X-FDA: 80519625396.02.23A9432 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf03.hostedemail.com (Postfix) with ESMTP id C6D2F20011 for ; Wed, 1 Mar 2023 08:17:36 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JlAQjb1M; spf=pass (imf03.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677658656; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/tLauRQV1B3hnnUPSxsMckjh3y/LZpZ2s1hZ7Yohe9w=; b=Irb8kjvf2TW+XH+TeK227UQI1eV2IaZ4aA6/1kNZwyYeP7GBc/GSu+owW0lYFD70mUlOxK 6cQV56N3rbEfPe91HqbwwnGRq/d7w8NtYtV98F037KCdr7Vv2tqj5JLRvMLrfwLVdMuGJL 2fBMACDrsmr7afD/+Gwed1pRQVsp6yg= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JlAQjb1M; spf=pass (imf03.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677658656; a=rsa-sha256; cv=none; b=NmVJaze/wqAuqUDjReMBLUm39tWsPHzm/eOkd8SL2NskPdKtjTj7XO1bof7Uk7D+TLoEhB djM/I8hjJleqNkCrOFH5rO2+tWdIIJA+NkrN3q73EQb9HDRPCmqTDMuqj6hHZhJ14X8tzv HouLOpnL8I8lR7tT6pcR9SWa24ZDNCg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677658656; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/tLauRQV1B3hnnUPSxsMckjh3y/LZpZ2s1hZ7Yohe9w=; b=JlAQjb1MficKkNRbxIR35wz7wrc9JCQbrvul6nmNCEHuvI13maD44SmaAch+EcZD3NGYSz ON4bQPhSSZ4U4uekiXwxM9aerT3ICDyma1JDJxTVS374bUxgizNIxs2qagAdPgS9Be48DF hdeocgEzR+aW7qpWrEiUxNE1OKe/lDA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-98-MW7yjL-hMzCLnY_PVtPqlw-1; Wed, 01 Mar 2023 03:17:32 -0500 X-MC-Unique: MW7yjL-hMzCLnY_PVtPqlw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 977E23814581; Wed, 1 Mar 2023 08:17:31 +0000 (UTC) Received: from localhost (ovpn-13-180.pek2.redhat.com [10.72.13.180]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 92F7040B40DF; Wed, 1 Mar 2023 08:17:29 +0000 (UTC) Date: Wed, 1 Mar 2023 16:17:25 +0800 From: Baoquan He To: "lizhijian@fujitsu.com" Cc: "kexec@lists.infradead.org" , "nvdimm@lists.linux.dev" , "linux-mm@kvack.org" , "vgoyal@redhat.com" , "dyoung@redhat.com" , "vishal.l.verma@intel.com" , "dan.j.williams@intel.com" , "dave.jiang@intel.com" , "horms@verge.net.au" , "k-hagio-ab@nec.com" , "akpm@linux-foundation.org" , "Yasunori Gotou (Fujitsu)" , "yangx.jy@fujitsu.com" , "ruansy.fnst@fujitsu.com" Subject: Re: [RFC][nvdimm][crash] pmem memmap dump support Message-ID: References: <3c752fc2-b6a0-2975-ffec-dba3edcf4155@fujitsu.com> <777f338f-09cb-d9f4-fe5f-3a6f059e4b02@fujitsu.com> MIME-Version: 1.0 In-Reply-To: <777f338f-09cb-d9f4-fe5f-3a6f059e4b02@fujitsu.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 4cscnkaue9c5psejqkam7h5358us1wbk X-Rspamd-Queue-Id: C6D2F20011 X-HE-Tag: 1677658656-94959 X-HE-Meta: U2FsdGVkX1+j2A9QFphMa/xYisJQ1MbJHPf98B+aMVQP94axHW7RvGp7wRDZjNr5XRhmpYJEJjYkmfyMYMtV6xC8o5WjpXS4rznDdEnQsrruQs4XaPTsi4IwVWTvj/raVbV10yYXCZmNc9JWKl1n7u7f5JW/XBF5dOMPxW0JR0GgxCBHaLmE+7ykduW+XgqH1FZ29Cu3/HXVfTEhZWscQnfy2c8+0qvwminqEO6aiyz4ozs+dlIfKclkokXICl9SxdRyAQfgDwuBYZfECggzLEnAl7/ynjcGgMONR2z/H00MfqPfg5WDR82X27FfNPtRe7boyjcdC3TSP5zGkADxzfhYbkaXM/BnEG/nVrKAhX+OMFWRL9sFd2M9843V0LrFKjXzkROLa3RSyYWUbWhVb6xomIIOxyg6wQxUJXuOSA6IcU64BV4VUP3iUwfF82AN3SVWQOBPR+zVaLHxU6gxRxM1ILTsSMj9hphuvuWRjRqecFUmCQj9aNl4O1dOeNVqU6VIZuJKF7qZydunI2XFv2CKNnuX3ynlCzUcZa9jFYc9vB32+VymF4+R1eQLcUNx+eYCDgR70dKK+lPkJg1k3u0uS8zuCAD4ZBxnyKUOvYZYzitLyIRB9Y6l7Ua/Mm0XWtWz6TKguPsftMoCy+33M/0ZovOoSae7c0gPhka8cIr5siU2dR6wcWtuPzwzpNMDavGuHKXoIXQqECcmEYaSy+sioCbbc1nFzaY5DaAhJjFeG/xs1LVovJ5w+V042eQUsv7jijysm0mwjFUhKGqcUiiVyk4h2ag+5j+jNoVPhlaflMmJjdniHSrFDYh4KUiWs5Ld2d3xXMg24+N/23ZjIkLmoGgieEhUnPcw4MJdmwTGb0Fx9gCWelh7Y8ONEkkNoITkkNFR8ZzOyNOlfsXRh0+KH0cT5ctf/L7SRmwREuaybWCP0MExe+Cn9FbE3/SP3kHGQihjqaXWA5cicEO GexhHQkX Jtip7WQCMYvKl128bKwPhRC+TDsjtvO4wmsX9lA2qLIDgWYYU6WCfmLQ/n9FnV2/uMKjVKra9TWqpmLMl49M0YlsN/ZWYpaaUq/SVxOPsFbzSAmkQSd2R5hh1zqXgXVORLXla2ehj8AsM+8Q7WomHT27R+ZZ7t3XsWwHeeby3cbBBx8Ms/exttE7DHJmPznC9pljzI3OzTAeEZxzOEv+WFEL6PeVoCRgKl6iCH1pk0teWSlf7eavdlMnzaMlhMQgjc6R2SJqMIPOFT1OCreHTFJHppg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 03/01/23 at 06:27am, lizhijian@fujitsu.com wrote: ...... > Hi Baoquan > > Greatly appreciate your feedback. > > > > 1) In kernel side, export info of pmem meta data; > > 2) in makedumpfile size, add an option to specify if we want to dump > > pmem meta data; An option or in dump level? > > Yes, I'm working on these 2 step. > > > 3) In glue script, detect and warn if pmem data is in pmem and wanted, > > and dump target is the same pmem. > > > > The 'glue script' means the scirpt like '/usr/bin/kdump.sh' in 2nd kernel? That would be an option, > Shall we abort this dump if "pmem data is in pmem and wanted, and dump target is the same pmem" ? Guess you are saying scripts in RHEL/centos/fedora, and yes if I guess righ. Other distros could have different scripts. For kdump, we need load kdump kernel/initramfs in advance, then wait to capture any crash. When we load, we can detect and check whether the environment and setup is expected. If not, we can warn or error out message to users. We don't need to do the checking until crash is triggered, then decide to abort the dump or not. > > Does this work for you? > > > > Not sure if above items are all do-able. As for parking pmem device > > till in kdump kernel, I believe intel pmem expert know how to achieve > > that. If there's no way to park pmem during kdump jumping, case D) is > > daydream. > > What's "kdump jumping" timing here ? > A. 1st kernel crashed and jumping to 2nd kernel or > B. 2nd/kdump kernel do the dump operation. > > In my understanding, dumping application(makedumpfile) in kdump kernel will do the dump operation > after modules loaded. Does "parking pmem" mean to postpone pmem modules loading until dump > operation finished ? if so, i think it has the same effect with disabling pmem device in kdump kernel. I used parking which should be wrong. When crash happened, we currently only shutdown unrelated CPU and interupt controller, but keep other devices on-flight. This is why we can preserve the content of crash-ed kernel's memory. For normal memory device, we reserve small part as crashkernel to run kdump kernel and dumping, keep the 1st kernel's memory untouched. For pmem, we may need to do something similar to keep its content untouched. I am not sure if disabling pmem device is the thing we need do in kdump kernel, what we want is 1) not shutdown pmem in 1st kernel when crash-ed 2) do not re-initialize pmem, at least do not remove its content 1) has been there with the current handling. We need do something to guarantee 2)? I don't know pmem well, just personal thought.