Message ID | 20230527123439.772-3-thunder.leizhen@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp307678vqr; Sat, 27 May 2023 05:37:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ69Onn5dkCDql9WN9n6XNzVDxC0PKg2FzEmN9uh43LgXEkct8CxsM6OOCJutNhUlu3kABKu X-Received: by 2002:a05:6a20:918e:b0:f2:ba78:3d50 with SMTP id v14-20020a056a20918e00b000f2ba783d50mr3183826pzd.12.1685191072992; Sat, 27 May 2023 05:37:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685191072; cv=none; d=google.com; s=arc-20160816; b=wqg2JE/5UpBiL1t2Ms1is+pPFZnbGhZ/Q9v04OJ3xOjv9wNnK7OdEFuHf8CHxw2vEv /MSYzCyCRPVpW4Rpfvl/0VttKURsvaNbTOW9negJ2aLHig9Is898EPTZBp4MUQs4Psuu UIrvD7xIAIymwmCIMuxrQm3Saw4zNqoAuiWjafh3CLG7fT3u459KZr5claaQAlP/HKYV 9zoGeaNHydFCumsEX0Ja/5iJKeB5bGOOiCmzx3ItOPz2fVOlKMOYDW9XzHciMtzvfs6I MB88eCjZRxBxJsQ+HsWghQXOEhkfQfvUf+de9Kf+A7XsNiN2YsRiWPn0eYVffvVudSuC UEuw== 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=CUP6nBkgrdvZW7dvpRkHgWKqxWP2IxmsAM9FafkcDZY=; b=XDmP6mbfFInTb3sRrk7lPzpGUbl2xTXnlPTM5NWYgauCeI+4/RgqJbgEwSGFRB066J 8zMHBKK2JyTBz4hI1hgGZxqddnxXpk5n3yKsQMxxZbufi5MkFxRgiMvUGeNcpXGu90ys n4a1X1ZSLPUKW+ABCI2D45cQz+/CIIvSVUFIPWB4Ec8+400An7eVpaT+isT40Lg6e8m4 6GrGLaHqnwaCsCHXnjpUv3drX5RaGJ768xcM5iyWrjjYAEhFq4nxuAMJRg+z5IBXON2p efPieqU23s+PAxkG/TFa4yhK3g/kwdDdfN9gLEEierVb8E1NW4O86ZmreD3ti/cXefjY 5f5g== 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q12-20020aa7960c000000b0064d3a475274si6421376pfg.75.2023.05.27.05.37.29; Sat, 27 May 2023 05:37:52 -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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232575AbjE0MgO (ORCPT <rfc822;zhanglyra.2023@gmail.com> + 99 others); Sat, 27 May 2023 08:36:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232541AbjE0MgL (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 27 May 2023 08:36:11 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B3A91BB for <linux-kernel@vger.kernel.org>; Sat, 27 May 2023 05:35:51 -0700 (PDT) Received: from dggpemm500006.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4QT1V75096zTkf3; Sat, 27 May 2023 20:35:43 +0800 (CST) Received: from thunder-town.china.huawei.com (10.174.178.55) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Sat, 27 May 2023 20:35:47 +0800 From: Zhen Lei <thunder.leizhen@huawei.com> To: Eric Biederman <ebiederm@xmission.com>, Baoquan He <bhe@redhat.com>, <kexec@lists.infradead.org>, <linux-kernel@vger.kernel.org> CC: Zhen Lei <thunder.leizhen@huawei.com>, Michael Holzheu <holzheu@linux.vnet.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, Amerigo Wang <amwang@redhat.com> Subject: [PATCH 2/6] kexec: delete a useless check in crash_shrink_memory() Date: Sat, 27 May 2023 20:34:35 +0800 Message-ID: <20230527123439.772-3-thunder.leizhen@huawei.com> X-Mailer: git-send-email 2.37.3.windows.1 In-Reply-To: <20230527123439.772-1-thunder.leizhen@huawei.com> References: <20230527123439.772-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767050914710754119?= X-GMAIL-MSGID: =?utf-8?q?1767050914710754119?= |
Series |
kexec: enable kexec_crash_size to support two crash kernel regions
|
|
Commit Message
Zhen Lei
May 27, 2023, 12:34 p.m. UTC
The check '(crashk_res.parent != NULL)' is added by
commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's
stale now. Because if 'crashk_res' is not reserved, it will be zero in
size and will be intercepted by the above 'if (new_size >= old_size)'.
Ago:
if (new_size >= end - start + 1)
Now:
old_size = (end == 0) ? 0 : end - start + 1;
if (new_size >= old_size)
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
kernel/kexec_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 05/27/23 at 08:34pm, Zhen Lei wrote: > The check '(crashk_res.parent != NULL)' is added by > commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's > stale now. Because if 'crashk_res' is not reserved, it will be zero in > size and will be intercepted by the above 'if (new_size >= old_size)'. > > Ago: > if (new_size >= end - start + 1) > > Now: > old_size = (end == 0) ? 0 : end - start + 1; > if (new_size >= old_size) Hmm, I would strongly suggest we keep that check. Even though the current code like above can do the acutal checking, but its actual usage is not obvious for checking of crashk_res existence. In the future, someone may change above calculation and don't notice the hidden functionality at all behind the calculation. The cost of the check is almost zero, right? > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > --- > kernel/kexec_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > index 22acee18195a591..d1ab139dd49035e 100644 > --- a/kernel/kexec_core.c > +++ b/kernel/kexec_core.c > @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size) > end = start + new_size; > crash_free_reserved_phys_range(end, crashk_res.end); > > - if ((start == end) && (crashk_res.parent != NULL)) > + if (start == end) > release_resource(&crashk_res); > > ram_res->start = end; > -- > 2.25.1 >
On 2023/5/31 8:17, Baoquan He wrote: > On 05/27/23 at 08:34pm, Zhen Lei wrote: >> The check '(crashk_res.parent != NULL)' is added by >> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's >> stale now. Because if 'crashk_res' is not reserved, it will be zero in >> size and will be intercepted by the above 'if (new_size >= old_size)'. >> >> Ago: >> if (new_size >= end - start + 1) >> >> Now: >> old_size = (end == 0) ? 0 : end - start + 1; >> if (new_size >= old_size) > > Hmm, I would strongly suggest we keep that check. Even though the > current code like above can do the acutal checking, but its actual usage > is not obvious for checking of crashk_res existence. In the future, > someone may change above calculation and don't notice the hidden > functionality at all behind the calculation. The cost of the check is > almost zero, right? The cost of the check is negligible. The only downside is that it's hard to understand why it's added, and I only found out why by looking at the history log. In my opinion, the above 'Now:' is the right fix. > >> >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >> --- >> kernel/kexec_core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c >> index 22acee18195a591..d1ab139dd49035e 100644 >> --- a/kernel/kexec_core.c >> +++ b/kernel/kexec_core.c >> @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size) >> end = start + new_size; >> crash_free_reserved_phys_range(end, crashk_res.end); >> >> - if ((start == end) && (crashk_res.parent != NULL)) >> + if (start == end) >> release_resource(&crashk_res); >> >> ram_res->start = end; >> -- >> 2.25.1 >> > > . >
On 05/31/23 at 10:19am, Leizhen (ThunderTown) wrote: > > > On 2023/5/31 8:17, Baoquan He wrote: > > On 05/27/23 at 08:34pm, Zhen Lei wrote: > >> The check '(crashk_res.parent != NULL)' is added by > >> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's > >> stale now. Because if 'crashk_res' is not reserved, it will be zero in > >> size and will be intercepted by the above 'if (new_size >= old_size)'. > >> > >> Ago: > >> if (new_size >= end - start + 1) > >> > >> Now: > >> old_size = (end == 0) ? 0 : end - start + 1; > >> if (new_size >= old_size) > > > > Hmm, I would strongly suggest we keep that check. Even though the > > current code like above can do the acutal checking, but its actual usage > > is not obvious for checking of crashk_res existence. In the future, > > someone may change above calculation and don't notice the hidden > > functionality at all behind the calculation. The cost of the check is > > almost zero, right? > > The cost of the check is negligible. The only downside is that it's hard to > understand why it's added, and I only found out why by looking at the history > log. In my opinion, the above 'Now:' is the right fix. It checks if the resource exists before releasing, just a normal checking? > > > > >> > >> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> > >> --- > >> kernel/kexec_core.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c > >> index 22acee18195a591..d1ab139dd49035e 100644 > >> --- a/kernel/kexec_core.c > >> +++ b/kernel/kexec_core.c > >> @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size) > >> end = start + new_size; > >> crash_free_reserved_phys_range(end, crashk_res.end); > >> > >> - if ((start == end) && (crashk_res.parent != NULL)) > >> + if (start == end) > >> release_resource(&crashk_res); > >> > >> ram_res->start = end; > >> -- > >> 2.25.1 > >> > > > > . > > > > -- > Regards, > Zhen Lei >
On 2023/5/31 15:41, Baoquan He wrote: > On 05/31/23 at 10:19am, Leizhen (ThunderTown) wrote: >> >> >> On 2023/5/31 8:17, Baoquan He wrote: >>> On 05/27/23 at 08:34pm, Zhen Lei wrote: >>>> The check '(crashk_res.parent != NULL)' is added by >>>> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's >>>> stale now. Because if 'crashk_res' is not reserved, it will be zero in >>>> size and will be intercepted by the above 'if (new_size >= old_size)'. >>>> >>>> Ago: >>>> if (new_size >= end - start + 1) >>>> >>>> Now: >>>> old_size = (end == 0) ? 0 : end - start + 1; >>>> if (new_size >= old_size) >>> >>> Hmm, I would strongly suggest we keep that check. Even though the >>> current code like above can do the acutal checking, but its actual usage >>> is not obvious for checking of crashk_res existence. In the future, >>> someone may change above calculation and don't notice the hidden >>> functionality at all behind the calculation. The cost of the check is >>> almost zero, right? >> >> The cost of the check is negligible. The only downside is that it's hard to >> understand why it's added, and I only found out why by looking at the history >> log. In my opinion, the above 'Now:' is the right fix. > > It checks if the resource exists before releasing, just a normal > checking? If resource_size(&crashk_res) is zero, it means that crashk_res has not been added(insert_resource) or has been deleted(release_resource). I've tested it. It's okay. >> >>> >>>> >>>> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> >>>> --- >>>> kernel/kexec_core.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c >>>> index 22acee18195a591..d1ab139dd49035e 100644 >>>> --- a/kernel/kexec_core.c >>>> +++ b/kernel/kexec_core.c >>>> @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size) >>>> end = start + new_size; >>>> crash_free_reserved_phys_range(end, crashk_res.end); >>>> >>>> - if ((start == end) && (crashk_res.parent != NULL)) >>>> + if (start == end) >>>> release_resource(&crashk_res); >>>> >>>> ram_res->start = end; >>>> -- >>>> 2.25.1 >>>> >>> >>> . >>> >> >> -- >> Regards, >> Zhen Lei >> > > > . >
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c index 22acee18195a591..d1ab139dd49035e 100644 --- a/kernel/kexec_core.c +++ b/kernel/kexec_core.c @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size) end = start + new_size; crash_free_reserved_phys_range(end, crashk_res.end); - if ((start == end) && (crashk_res.parent != NULL)) + if (start == end) release_resource(&crashk_res); ram_res->start = end;