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 379DAC433F5 for ; Thu, 31 Mar 2022 11:23:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A55C86B0072; Thu, 31 Mar 2022 07:23:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A058C6B0073; Thu, 31 Mar 2022 07:23:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CCB96B0074; Thu, 31 Mar 2022 07:23:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id 7D49B6B0072 for ; Thu, 31 Mar 2022 07:23:53 -0400 (EDT) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 33BBC182A5ECF for ; Thu, 31 Mar 2022 11:23:53 +0000 (UTC) X-FDA: 79304446746.18.AD20A41 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf06.hostedemail.com (Postfix) with ESMTP id 706D8180016 for ; Thu, 31 Mar 2022 11:23:52 +0000 (UTC) Received: from kwepemi500016.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KTgsZ6D8tz1GCx2; Thu, 31 Mar 2022 19:23:30 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500016.china.huawei.com (7.221.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 31 Mar 2022 19:23:49 +0800 Received: from [10.174.179.19] (10.174.179.19) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 31 Mar 2022 19:23:48 +0800 Message-ID: Date: Thu, 31 Mar 2022 19:23:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH] hugetlb: Fix hugepages_setup when deal with pernode Content-Language: en-US To: Mike Kravetz , , , , , References: <20220324074037.2024608-1-liupeng256@huawei.com> <361111c6-921b-e129-edf3-367748f6497e@oracle.com> From: "liupeng (DM)" In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed X-Originating-IP: [10.174.179.19] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 706D8180016 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf06.hostedemail.com: domain of liupeng256@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=liupeng256@huawei.com X-Stat-Signature: f9r7mnom1pp3ziugifmrrydweodnzpou X-HE-Tag: 1648725832-589046 Content-Transfer-Encoding: quoted-printable 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 2022/3/30 1:43, Mike Kravetz wrote: > On 3/28/22 20:59, liupeng (DM) wrote: >> On 2022/3/29 10:46, Mike Kravetz wrote: >>> Yes, I agree that the change is needed and the current behavior is >>> unacceptable. >>> >>> One remaining question is the change from returning '0' to '1' in the= case >>> of error.=C2=A0 I do understand this is to prevent the invalid parame= ter string >>> from being passed to init.=C2=A0 It may not be correct/right, but in = every other >>> case where an invalid parameter in encountered in hugetlb command lin= e >>> processing we return "0".=C2=A0 Should we perhaps change all these ot= her places >>> to be consistent?=C2=A0 I honestly do not know what is the appropriat= e behavior >>> in these situations. >> Thank you for your carefulness and question. >> >> I have checked default_hugepagesz_setup and hugepages_setup will both = print >> some information before return '0', so there is no need to print again= in >> "Unknown kernel command line parameters". >> >> Should I send another patch to repair the rest "return 0" in hugetlb? > I would suggest two patches: > > 1) Fix the issue with invalid nodes specified. However, leave the "ret= urn 0" > behavior in hugepages_setup to be consistent with the rest of the c= ode. > This patch can be sent to stable with "Fixes: b5389086ad7b" tag as = it > addresses an existing issue. > 2) Clean up the places where we return 0 and it would be better to retu= rn 1. > No cc stable here and just let the changes target future releases. I have tried to write a patch as your suggestion, but the best way I can=20 carry it out is the original patch. To meet "Fix invalid nodes issue and leave=20 thereturn 0 behavior", I have to add the following redundant code: =C2=A0invalid: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pr_warn("HugeTLB: Invalid hug= epages parameter %s\n", p); + +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Allocate gigantic hstates for su= ccessfully parsed parameters*/ +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (hugetlb_max_hstate && hstate_is= _gigantic(parsed_hstate)) + hugetlb_hstate_alloc_pages(parsed_hstate); +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 last_mhp =3D mhp; return 0; Any ideas?