Message ID | 20230922030722.708267-1-chenjiahao16@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp5294430vqi; Thu, 21 Sep 2023 20:25:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFLAQ/5sRmX5Rx7t1RsgjceEjzUHgGImBF0C+dZwQKUiIZ8cviFCpGoBFhUlOOIvhBdRafF X-Received: by 2002:a05:6808:8e3:b0:3a7:b094:8f2 with SMTP id d3-20020a05680808e300b003a7b09408f2mr7456527oic.45.1695353112329; Thu, 21 Sep 2023 20:25:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695353112; cv=none; d=google.com; s=arc-20160816; b=WwatvL8WJ20kAKI50/d57R4TnDZfbKC861/UtiRfuy0lMFcJGGwwfnrHVSokDIz7ZU iUtC359pct8sU7c0x+eZ4onATgekOuh+83kcfMukfkXAtlVnICImbWog5fZavQDa212a Zhjp0J6mbeThVMuCbgJAo8q1H/+eCZ8PmGPpaPQPUUH1ALVX+cwqa5FJ8pJT8lcSPRZn t1PR4f4ya0HMj7ZdeTsuJomqzPggLw+u79B2SYAXRst+kNxBIYAAGXe4mlB8DZvVkNrl RCyar+j3xPyMwjaFz25YdDWO/RH1Di0ZPdzXXeP41OErdC3/T/KZMNc9Zhj904WKpwNt 68sQ== 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 :message-id:date:subject:cc:to:from; bh=/uwaaWoE+2UYAMDHOeqoPYG6vkVFf6ArM2ZgZzAC+j4=; fh=SpN9CFJ/p0uuiqaD4wHkVoHbmmbtM5y2/it5hbgDvo4=; b=NMBnjA+pub3ZgXt4wKe7sWNSEkHdFPwpIplzIkvMzMcr3kEent2OpiiOvKNEY2JgbI pxHjJnwEXfeHrNRDq/zJ80wzS4CygjG9UYOFjDGVAB+whIkobbsr4mLEQzRqElJ3mZzf PrZRcpK2OQr0LS295JfLnTiBa5fckD671bWlK8NMCFBYeIlJstyq2o1Lzq9HhGirx0qu hV0SdgmOP8fDVl7XvwHKMJ1xSQh8FWqxuBwTp5ZUUYIAVKA2v2hafzUPSh7WJa0eOT5E pOPwQwHUcruwR4lRBZq8xHrYCnqWSomwT/CN6SEuMWFGuNazFDRwj7boWLMjlPTirGWU yvGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id k17-20020a056a00135100b0068fba252466si2802665pfu.169.2023.09.21.20.25.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Sep 2023 20:25:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 3818782FABDF; Thu, 21 Sep 2023 20:07:50 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230046AbjIVDHn (ORCPT <rfc822;chrisfriedt@gmail.com> + 30 others); Thu, 21 Sep 2023 23:07:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229912AbjIVDHl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 21 Sep 2023 23:07:41 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 321578F for <linux-kernel@vger.kernel.org>; Thu, 21 Sep 2023 20:07:35 -0700 (PDT) Received: from dggpemm500016.china.huawei.com (unknown [172.30.72.53]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4RsHFc2lDXzrT16; Fri, 22 Sep 2023 11:05:24 +0800 (CST) Received: from huawei.com (10.67.174.58) by dggpemm500016.china.huawei.com (7.185.36.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Fri, 22 Sep 2023 11:07:32 +0800 From: Chen Jiahao <chenjiahao16@huawei.com> To: <bhe@redhat.com>, <thunder.leizhen@huawei.com>, <paul.walmsley@sifive.com>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>, <conor.dooley@microchip.com>, <alexghiti@rivosinc.com>, <ajones@ventanamicro.com>, <jszhang@kernel.org>, <sunilvl@ventanamicro.com>, <robh@kernel.org>, <bjorn@rivosinc.com>, <zephray@outlook.com>, <akpm@linux-foundation.org>, <linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org> CC: <chenjiahao16@huawei.com> Subject: [PATCH -next] riscv: kdump: fix crashkernel reserving problem on RISC-V Date: Fri, 22 Sep 2023 11:07:22 +0800 Message-ID: <20230922030722.708267-1-chenjiahao16@huawei.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.67.174.58] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm500016.china.huawei.com (7.185.36.25) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 21 Sep 2023 20:07:50 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777706585357956159 X-GMAIL-MSGID: 1777706585357956159 |
Series |
[-next] riscv: kdump: fix crashkernel reserving problem on RISC-V
|
|
Commit Message
Chen Jiahao
Sept. 22, 2023, 3:07 a.m. UTC
When testing on risc-v QEMU environment with "crashkernel="
parameter enabled, a problem occurred with the following
message:
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x0000000177e00000 - 0x0000000277e00000 (4096 MB)
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:779 __insert_resource+0x8e/0xd0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc2-next-20230920 #1
[ 0.000000] Hardware name: riscv-virtio,qemu (DT)
[ 0.000000] epc : __insert_resource+0x8e/0xd0
[ 0.000000] ra : insert_resource+0x28/0x4e
[ 0.000000] epc : ffffffff80017344 ra : ffffffff8001742e sp : ffffffff81203db0
[ 0.000000] gp : ffffffff812ece98 tp : ffffffff8120dac0 t0 : ff600001f7ff2b00
[ 0.000000] t1 : 0000000000000000 t2 : 3428203030303030 s0 : ffffffff81203dc0
[ 0.000000] s1 : ffffffff81211e18 a0 : ffffffff81211e18 a1 : ffffffff81289380
[ 0.000000] a2 : 0000000277dfffff a3 : 0000000177e00000 a4 : 0000000177e00000
[ 0.000000] a5 : ffffffff81289380 a6 : 0000000277dfffff a7 : 0000000000000078
[ 0.000000] s2 : ffffffff81289380 s3 : ffffffff80a0bac8 s4 : ff600001f7ff2880
[ 0.000000] s5 : 0000000000000280 s6 : 8000000a00006800 s7 : 000000000000007f
[ 0.000000] s8 : 0000000080017038 s9 : 0000000080038ea0 s10: 0000000000000000
[ 0.000000] s11: 0000000000000000 t3 : ffffffff80a0bc00 t4 : ffffffff80a0bc00
[ 0.000000] t5 : ffffffff80a0bbd0 t6 : ffffffff80a0bc00
[ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003
[ 0.000000] [<ffffffff80017344>] __insert_resource+0x8e/0xd0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Failed to add a Crash kernel resource at 177e00000
The crashkernel memory has been allocated successfully, whereas
it failed to insert into iomem_resource. This is due to the
unique reserving logic in risc-v arch specific code, i.e.
crashk_res/crashk_low_res will be added into iomem_resource
later in init_resources(), which is not aligned with current
unified reserving logic in reserve_crashkernel_generic()/
reserve_crashkernel_low().
Removing the arch specific code within #ifdef CONFIG_KEXEC_CORE
in init_resources() to fix above problem.
Fixes: 31549153088e ("riscv: kdump: use generic interface to simplify crashkernel reservation")
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
---
arch/riscv/kernel/setup.c | 13 -------------
1 file changed, 13 deletions(-)
Comments
Hi Jiahao, On 09/22/23 at 11:07am, Chen Jiahao wrote: > When testing on risc-v QEMU environment with "crashkernel=" > parameter enabled, a problem occurred with the following > message: > > [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) > [ 0.000000] crashkernel reserved: 0x0000000177e00000 - 0x0000000277e00000 (4096 MB) > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:779 __insert_resource+0x8e/0xd0 > [ 0.000000] Modules linked in: > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc2-next-20230920 #1 > [ 0.000000] Hardware name: riscv-virtio,qemu (DT) > [ 0.000000] epc : __insert_resource+0x8e/0xd0 > [ 0.000000] ra : insert_resource+0x28/0x4e > [ 0.000000] epc : ffffffff80017344 ra : ffffffff8001742e sp : ffffffff81203db0 > [ 0.000000] gp : ffffffff812ece98 tp : ffffffff8120dac0 t0 : ff600001f7ff2b00 > [ 0.000000] t1 : 0000000000000000 t2 : 3428203030303030 s0 : ffffffff81203dc0 > [ 0.000000] s1 : ffffffff81211e18 a0 : ffffffff81211e18 a1 : ffffffff81289380 > [ 0.000000] a2 : 0000000277dfffff a3 : 0000000177e00000 a4 : 0000000177e00000 > [ 0.000000] a5 : ffffffff81289380 a6 : 0000000277dfffff a7 : 0000000000000078 > [ 0.000000] s2 : ffffffff81289380 s3 : ffffffff80a0bac8 s4 : ff600001f7ff2880 > [ 0.000000] s5 : 0000000000000280 s6 : 8000000a00006800 s7 : 000000000000007f > [ 0.000000] s8 : 0000000080017038 s9 : 0000000080038ea0 s10: 0000000000000000 > [ 0.000000] s11: 0000000000000000 t3 : ffffffff80a0bc00 t4 : ffffffff80a0bc00 > [ 0.000000] t5 : ffffffff80a0bbd0 t6 : ffffffff80a0bc00 > [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > [ 0.000000] [<ffffffff80017344>] __insert_resource+0x8e/0xd0 > [ 0.000000] ---[ end trace 0000000000000000 ]--- > [ 0.000000] Failed to add a Crash kernel resource at 177e00000 > > The crashkernel memory has been allocated successfully, whereas > it failed to insert into iomem_resource. This is due to the This is a warning, not a failure, right? Inserting crashk_*res into iomem_resource has been successful, just the repeated inserting cause the warning. Maybe, we should tell this in log clearly? Other than minor concern, this looks good to me, thanks for the testing and this fix: Acked-by: Baoquan He <bhe@redhat.com> Thanks Baoquan > unique reserving logic in risc-v arch specific code, i.e. > crashk_res/crashk_low_res will be added into iomem_resource > later in init_resources(), which is not aligned with current > unified reserving logic in reserve_crashkernel_generic()/ > reserve_crashkernel_low(). > > Removing the arch specific code within #ifdef CONFIG_KEXEC_CORE > in init_resources() to fix above problem. > > Fixes: 31549153088e ("riscv: kdump: use generic interface to simplify crashkernel reservation") > Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> > --- > arch/riscv/kernel/setup.c | 13 ------------- > 1 file changed, 13 deletions(-) > > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c > index e600aab116a4..aac853ae4eb7 100644 > --- a/arch/riscv/kernel/setup.c > +++ b/arch/riscv/kernel/setup.c > @@ -173,19 +173,6 @@ static void __init init_resources(void) > if (ret < 0) > goto error; > > -#ifdef CONFIG_KEXEC_CORE > - if (crashk_res.start != crashk_res.end) { > - ret = add_resource(&iomem_resource, &crashk_res); > - if (ret < 0) > - goto error; > - } > - if (crashk_low_res.start != crashk_low_res.end) { > - ret = add_resource(&iomem_resource, &crashk_low_res); > - if (ret < 0) > - goto error; > - } > -#endif > - > #ifdef CONFIG_CRASH_DUMP > if (elfcorehdr_size > 0) { > elfcorehdr_res.start = elfcorehdr_addr; > -- > 2.34.1 >
On 2023/9/22 15:16, Baoquan He wrote: > Hi Jiahao, > > On 09/22/23 at 11:07am, Chen Jiahao wrote: >> When testing on risc-v QEMU environment with "crashkernel=" >> parameter enabled, a problem occurred with the following >> message: >> >> [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) >> [ 0.000000] crashkernel reserved: 0x0000000177e00000 - 0x0000000277e00000 (4096 MB) >> [ 0.000000] ------------[ cut here ]------------ >> [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:779 __insert_resource+0x8e/0xd0 >> [ 0.000000] Modules linked in: >> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc2-next-20230920 #1 >> [ 0.000000] Hardware name: riscv-virtio,qemu (DT) >> [ 0.000000] epc : __insert_resource+0x8e/0xd0 >> [ 0.000000] ra : insert_resource+0x28/0x4e >> [ 0.000000] epc : ffffffff80017344 ra : ffffffff8001742e sp : ffffffff81203db0 >> [ 0.000000] gp : ffffffff812ece98 tp : ffffffff8120dac0 t0 : ff600001f7ff2b00 >> [ 0.000000] t1 : 0000000000000000 t2 : 3428203030303030 s0 : ffffffff81203dc0 >> [ 0.000000] s1 : ffffffff81211e18 a0 : ffffffff81211e18 a1 : ffffffff81289380 >> [ 0.000000] a2 : 0000000277dfffff a3 : 0000000177e00000 a4 : 0000000177e00000 >> [ 0.000000] a5 : ffffffff81289380 a6 : 0000000277dfffff a7 : 0000000000000078 >> [ 0.000000] s2 : ffffffff81289380 s3 : ffffffff80a0bac8 s4 : ff600001f7ff2880 >> [ 0.000000] s5 : 0000000000000280 s6 : 8000000a00006800 s7 : 000000000000007f >> [ 0.000000] s8 : 0000000080017038 s9 : 0000000080038ea0 s10: 0000000000000000 >> [ 0.000000] s11: 0000000000000000 t3 : ffffffff80a0bc00 t4 : ffffffff80a0bc00 >> [ 0.000000] t5 : ffffffff80a0bbd0 t6 : ffffffff80a0bc00 >> [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 >> [ 0.000000] [<ffffffff80017344>] __insert_resource+0x8e/0xd0 >> [ 0.000000] ---[ end trace 0000000000000000 ]--- >> [ 0.000000] Failed to add a Crash kernel resource at 177e00000 >> >> The crashkernel memory has been allocated successfully, whereas >> it failed to insert into iomem_resource. This is due to the > This is a warning, not a failure, right? Inserting crashk_*res into > iomem_resource has been successful, just the repeated inserting cause > the warning. Maybe, we should tell this in log clearly? Other than minor > concern, this looks good to me, thanks for the testing and this fix: Thanks for reviewing. Actually this is not only a warning message. Since when failure occurs in riscv's init_resources(), error: release_child_resources(&iomem_resource); will get called, already added crashkernel memory will hence get removed. To verify this, I have checked but cannot find crashkernel memory in /proc/iomem when this problem occurs. But you are right, it is necessary to make it clear what will eventually happen in commit message. I will update a v2 patch later to add these info. Thanks, Jiahao > > Acked-by: Baoquan He <bhe@redhat.com> > > Thanks > Baoquan > >> unique reserving logic in risc-v arch specific code, i.e. >> crashk_res/crashk_low_res will be added into iomem_resource >> later in init_resources(), which is not aligned with current >> unified reserving logic in reserve_crashkernel_generic()/ >> reserve_crashkernel_low(). >> >> Removing the arch specific code within #ifdef CONFIG_KEXEC_CORE >> in init_resources() to fix above problem. >> >> Fixes: 31549153088e ("riscv: kdump: use generic interface to simplify crashkernel reservation") >> Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> >> --- >> arch/riscv/kernel/setup.c | 13 ------------- >> 1 file changed, 13 deletions(-) >> >> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c >> index e600aab116a4..aac853ae4eb7 100644 >> --- a/arch/riscv/kernel/setup.c >> +++ b/arch/riscv/kernel/setup.c >> @@ -173,19 +173,6 @@ static void __init init_resources(void) >> if (ret < 0) >> goto error; >> >> -#ifdef CONFIG_KEXEC_CORE >> - if (crashk_res.start != crashk_res.end) { >> - ret = add_resource(&iomem_resource, &crashk_res); >> - if (ret < 0) >> - goto error; >> - } >> - if (crashk_low_res.start != crashk_low_res.end) { >> - ret = add_resource(&iomem_resource, &crashk_low_res); >> - if (ret < 0) >> - goto error; >> - } >> -#endif >> - >> #ifdef CONFIG_CRASH_DUMP >> if (elfcorehdr_size > 0) { >> elfcorehdr_res.start = elfcorehdr_addr; >> -- >> 2.34.1 >>
On 09/22/23 at 05:33pm, chenjiahao (C) wrote: > > On 2023/9/22 15:16, Baoquan He wrote: > > Hi Jiahao, > > > > On 09/22/23 at 11:07am, Chen Jiahao wrote: > > > When testing on risc-v QEMU environment with "crashkernel=" > > > parameter enabled, a problem occurred with the following > > > message: > > > > > > [ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB) > > > [ 0.000000] crashkernel reserved: 0x0000000177e00000 - 0x0000000277e00000 (4096 MB) > > > [ 0.000000] ------------[ cut here ]------------ > > > [ 0.000000] WARNING: CPU: 0 PID: 0 at kernel/resource.c:779 __insert_resource+0x8e/0xd0 > > > [ 0.000000] Modules linked in: > > > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc2-next-20230920 #1 > > > [ 0.000000] Hardware name: riscv-virtio,qemu (DT) > > > [ 0.000000] epc : __insert_resource+0x8e/0xd0 > > > [ 0.000000] ra : insert_resource+0x28/0x4e > > > [ 0.000000] epc : ffffffff80017344 ra : ffffffff8001742e sp : ffffffff81203db0 > > > [ 0.000000] gp : ffffffff812ece98 tp : ffffffff8120dac0 t0 : ff600001f7ff2b00 > > > [ 0.000000] t1 : 0000000000000000 t2 : 3428203030303030 s0 : ffffffff81203dc0 > > > [ 0.000000] s1 : ffffffff81211e18 a0 : ffffffff81211e18 a1 : ffffffff81289380 > > > [ 0.000000] a2 : 0000000277dfffff a3 : 0000000177e00000 a4 : 0000000177e00000 > > > [ 0.000000] a5 : ffffffff81289380 a6 : 0000000277dfffff a7 : 0000000000000078 > > > [ 0.000000] s2 : ffffffff81289380 s3 : ffffffff80a0bac8 s4 : ff600001f7ff2880 > > > [ 0.000000] s5 : 0000000000000280 s6 : 8000000a00006800 s7 : 000000000000007f > > > [ 0.000000] s8 : 0000000080017038 s9 : 0000000080038ea0 s10: 0000000000000000 > > > [ 0.000000] s11: 0000000000000000 t3 : ffffffff80a0bc00 t4 : ffffffff80a0bc00 > > > [ 0.000000] t5 : ffffffff80a0bbd0 t6 : ffffffff80a0bc00 > > > [ 0.000000] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 > > > [ 0.000000] [<ffffffff80017344>] __insert_resource+0x8e/0xd0 > > > [ 0.000000] ---[ end trace 0000000000000000 ]--- > > > [ 0.000000] Failed to add a Crash kernel resource at 177e00000 > > > > > > The crashkernel memory has been allocated successfully, whereas > > > it failed to insert into iomem_resource. This is due to the > > This is a warning, not a failure, right? Inserting crashk_*res into > > iomem_resource has been successful, just the repeated inserting cause > > the warning. Maybe, we should tell this in log clearly? Other than minor > > concern, this looks good to me, thanks for the testing and this fix: > > Thanks for reviewing. Actually this is not only a warning message. > Since when failure occurs in riscv's init_resources(), > > error: > release_child_resources(&iomem_resource); > > will get called, already added crashkernel memory will hence > get removed. To verify this, I have checked but cannot find > crashkernel memory in /proc/iomem when this problem occurs. I see, I was mistaken then. Thanks for telling.
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c index e600aab116a4..aac853ae4eb7 100644 --- a/arch/riscv/kernel/setup.c +++ b/arch/riscv/kernel/setup.c @@ -173,19 +173,6 @@ static void __init init_resources(void) if (ret < 0) goto error; -#ifdef CONFIG_KEXEC_CORE - if (crashk_res.start != crashk_res.end) { - ret = add_resource(&iomem_resource, &crashk_res); - if (ret < 0) - goto error; - } - if (crashk_low_res.start != crashk_low_res.end) { - ret = add_resource(&iomem_resource, &crashk_low_res); - if (ret < 0) - goto error; - } -#endif - #ifdef CONFIG_CRASH_DUMP if (elfcorehdr_size > 0) { elfcorehdr_res.start = elfcorehdr_addr;