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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B60CC433FE for ; Wed, 29 Dec 2021 02:27:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238388AbhL2C1l (ORCPT ); Tue, 28 Dec 2021 21:27:41 -0500 Received: from szxga03-in.huawei.com ([45.249.212.189]:30189 "EHLO szxga03-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229620AbhL2C1k (ORCPT ); Tue, 28 Dec 2021 21:27:40 -0500 Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4JNwGt6pFCz8w6F; Wed, 29 Dec 2021 10:25:10 +0800 (CST) Received: from dggpemm500006.china.huawei.com (7.185.36.236) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 29 Dec 2021 10:27:38 +0800 Received: from [10.174.178.55] (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.2308.20; Wed, 29 Dec 2021 10:27:37 +0800 Subject: Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code To: Borislav Petkov CC: Thomas Gleixner , Ingo Molnar , , "H . Peter Anvin" , , Dave Young , Baoquan He , Vivek Goyal , Eric Biederman , , Catalin Marinas , Will Deacon , , Rob Herring , Frank Rowand , , "Jonathan Corbet" , , Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou , "John Donnelly" References: <20211228132612.1860-1-thunder.leizhen@huawei.com> <20211228132612.1860-3-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: Date: Wed, 29 Dec 2021 10:27:36 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.55] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500006.china.huawei.com (7.185.36.236) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/12/29 0:13, Borislav Petkov wrote: > On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote: >> Use parse_crashkernel_high_low() to bring the parsing of >> "crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they >> are strongly dependent, make code logic clear and more readable. >> >> Suggested-by: Borislav Petkov > > Yeah, doesn't look like something I suggested... > >> @@ -474,10 +472,9 @@ static void __init reserve_crashkernel(void) >> /* crashkernel=XM */ >> ret = parse_crashkernel(boot_command_line, total_mem, &crash_size, &crash_base); >> if (ret != 0 || crash_size <= 0) { >> - /* crashkernel=X,high */ >> - ret = parse_crashkernel_high(boot_command_line, total_mem, >> - &crash_size, &crash_base); >> - if (ret != 0 || crash_size <= 0) >> + /* crashkernel=X,high and possible crashkernel=Y,low */ >> + ret = parse_crashkernel_high_low(boot_command_line, &crash_size, &low_size); > > So this calls parse_crashkernel() and when that one fails, it calls this > new weird parse high/low helper you added. > > But then all three end up in the same __parse_crashkernel() worker > function which seems to do the actual parsing. > > What I suggested and what would be real clean is if the arches would > simply call a *single* > > parse_crashkernel() > > function and when that one returns, *all* crashkernel= options would > have been parsed properly, low, high, middle crashkernel, whatever... > and the caller would know what crash kernel needs to be allocated. > > Then each arch can do its memory allocations and checks based on that > parsed data and decide to allocate or bail. However, only x86 currently supports "crashkernel=X,high" and "crashkernel=Y,low", and arm64 will also support it. It is not supported on other architectures. So changing parse_crashkernel() is not appropriate unless a new function is introduced. But naming this new function isn't easy, and the name parse_crashkernel_in_order() that I've named before doesn't seem to be good. Of course, we can also consider changing parse_crashkernel() to another name, then use parse_crashkernel() to parse all possible "crashkernel=" options in order, but this will cause other architectures to change as well. > > So it is getting there but it needs more surgery... > > Thx. > -- Regards, Zhen Lei