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 9439FC678D4 for ; Fri, 3 Mar 2023 09:21:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26B096B0072; Fri, 3 Mar 2023 04:21:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F4BD6B0073; Fri, 3 Mar 2023 04:21:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 095676B0078; Fri, 3 Mar 2023 04:21:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id ED97A6B0072 for ; Fri, 3 Mar 2023 04:21:46 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AC50A121154 for ; Fri, 3 Mar 2023 09:21:46 +0000 (UTC) X-FDA: 80527044612.20.04CE407 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 61791180005 for ; Fri, 3 Mar 2023 09:21:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=avG8U2G1; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.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=1677835303; 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=XjkqTVt2QtWZVOvq30arJHAo3lGgaTpqVjd41aCw5H0=; b=ZWUDQgtLL6/l9gHtSdEL6f2kkYjEv+63EPug1dBf78RSWy0lSJyf5okgOYJD0r49vT7yL4 xH7MHnADfomG7SHTdPUPi53lB6PpA8WUEcy5sIyG/dx+LycqqxwbFXDk/lDHyiGA2otdJf E+iAHyjpe/DxVmVLkPcAdDCCnkLDuKw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=avG8U2G1; spf=pass (imf24.hostedemail.com: domain of bhe@redhat.com designates 170.10.129.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=1677835303; a=rsa-sha256; cv=none; b=wjH2v3ogLzrabAJT48CMTSgSFhJ/IeVtO7octz4ou9MKjKKqHsza8EAT7YI1Kmaj//UqCw MaxztJZj0OWc23Dfo5wUibb+ToHm03m/NVDeUih600eYkHPGgmmIlswhy1qjLUwXIJUN6/ EHKMHbEXnSiXrJji2AldEENSoWlqYn4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677835302; 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=XjkqTVt2QtWZVOvq30arJHAo3lGgaTpqVjd41aCw5H0=; b=avG8U2G1wmjYN6yzS+foayP2HHMCuXbPSrtjFR2YNiLNFPNAAz9+/C4JL6egNM5+3abziH TwS6R4uTuCikvO4fImzDVQCFiU9BDkQiWWHDewIbt58KV0y6bRj8pkyvLO5te7yqk1BTZD zsegmrBfY6gT7yW7Hp5Hcnzs/R3aM28= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-205-vMJPGrxyObqdC6zLBD8I6A-1; Fri, 03 Mar 2023 04:21:38 -0500 X-MC-Unique: vMJPGrxyObqdC6zLBD8I6A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BA245803D50; Fri, 3 Mar 2023 09:21:37 +0000 (UTC) Received: from localhost (ovpn-13-150.pek2.redhat.com [10.72.13.150]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B15B82166B34; Fri, 3 Mar 2023 09:21:36 +0000 (UTC) Date: Fri, 3 Mar 2023 17:21:29 +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: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 61791180005 X-Rspam-User: X-Stat-Signature: n96ijcnyozzrnkajs4j4gs43o6pnkq9i X-HE-Tag: 1677835303-879190 X-HE-Meta: U2FsdGVkX1+d6+FIEDMsP4XRAInsQuwclFRezuxvvq4OCn1uKGhzXi0nyqPFaOo4MK6BXkqUYLR5328nLvCP/M7jJy2Ffspj/DTEQ3mFKi/m/tGwsRFA9hPJzBPKAO3IavKD+SwbIVbYwH28/r0WyNFX1k5Q9CFpQMEgtfWd/tTWkpERC0f6a9l7R0DDefj/21mv5MI6uHbmKFyFUWroALZqbkviSCLRN/kfFYOE+ZuOjNi/eG5dsGlDTHyIHg3Y+4HW1udKG6yF1FiigmHfi4Pawn1+6VcHuVGVvelqBOPFWxjY/lU1q+Emu9b0eakiXb80j1GqntU7gamsHYnR9Kz0rTPEa3gqDizxbWMU4ctjiL3w4yfIuCymsPxmRiTxx9aPM1e46JUb0zuAkJSQYoLgz8mKFODtnfUN9fMwGKDvPxzuma92gfv3Jo2KNZR8Hk9DGH+C4AH5dzB0mjtPrJM+c4M0gXf/eghgmaS/5K1Nq85XozPi2EiGbP+e4BM2KALAcm2XF8+H/6nWLV2JSqPEhBGcE33OOOAo4vfWP0wLWAP18FcxO0R38H9NhrOY0WjCKtE1oSeF+PXhy5XeysbSnt59EVn2kvmic80I5Z/QLy1GuSF+1tQ6oNTq8Pu8sjRHKCYKlIN1Gld5gyl94J63LlupBEVe6/Cp8wdvFwWiFOJISjLxLnRUfPKrCN5YfQhrbkzxaC2RtwZx9MyBgO1e41X5CpQPyt5I9+bfqtk5s1E6v0n+p5nhSDDGAtRrYiFIIw6uZ1FS1zcPvMWdmp+i0Cr+kAuOgXIGOIrIPXZPAii4zNPjWlmddDrV8u0fStQUTgIQYT+Sc6cdIufC8hAWUxxAEbiZgs3ZuAhSAfQihNMF/PFIzJZeV+GrUbFujCg3aV/qQVxNKgkBeSCUHjsdra/YI7I89MpjjRafN35wjY9HZ5x/NaWikyRPic3khO0zWRoCgi8cc+rgwbo m/Up1RYH PMiNqJjGCgvUYYl0JtnDFNFKogtT0mAFZ9c116oRrLwiAXTLug7WQQ6epmaZIstufm4k2CEOP/Wq4JHnJNAU0o5QGZWKd5aRNbmxfKBE64KZeBoDkhLmvBr5vdA1TzduJuhHKTNi6syTRYEOz/Kj1/NA6CpoMrGJNMIMRgMI6Gb40Wk9JUGxAWnGcZfcywp/aLU0YwV9Ze0hImpAr7XujctPbdZJ0GQm87tgxrDQ+lPvQqMoQLZNxq1VGHWCd0j+z2igPYafc6DEevWRYR1ZWGEkyLA== 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/03/23 at 02:27am, lizhijian@fujitsu.com wrote: > > > On 01/03/2023 16:17, Baoquan He wrote: > > 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. > > > IIUC, take fedora for example, > T1: in 1st kernel, kdump.service(/usr/bin/kdumpctl) will do a sanity check before loading kernel and initramfs. > In this moment, as you said "we can detect and check whether the environment and setup is expected. If not, > we can warn or error out message to users." > I think we should abort the kdump service if "pmem data is in pmem and wanted, and dump target is the same pmem". > For OS administrators, they could either change the dump target or disable the pmem metadadata dump to make > kdump.service work again. > > But kdump.service is distros independent, some OS administrators will use `kexec` command directly instead of service/script helpers. Yeah, we can add document in kernel or somewhere else that dumping to pmem is dangerous, especially when we want to dump pmem meta. People who dare use kexec command directly, should handle it by her/his own. > > > We don't need to do the checking until crash is triggered, then decide > > to abort the dump or not. > > T2: in 2nd kernel, since 1st kernel's glue scripts vary by distribution, we have to do the sanity check again to decide > to abort the dump or not. Hmm, we may not need to worry about that. kernel just need to do its own business, not touching pmem data during kdump jumping and booting, and provide way to allow makedumpfile to read out pmem meta. Anything else should be taken care of by user or distros.