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 BC1DCC433EF for ; Sat, 2 Apr 2022 01:34:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA9286B0071; Fri, 1 Apr 2022 21:34:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D58D88D0002; Fri, 1 Apr 2022 21:34:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFAE08D0001; Fri, 1 Apr 2022 21:34:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id B05AF6B0071 for ; Fri, 1 Apr 2022 21:34:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6A05D1828AE55 for ; Sat, 2 Apr 2022 01:34:05 +0000 (UTC) X-FDA: 79310218050.29.91173DC Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf15.hostedemail.com (Postfix) with ESMTP id B2AA4A0026 for ; Sat, 2 Apr 2022 01:34:03 +0000 (UTC) Received: from kwepemi500025.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KVffW2qGRzgY90; Sat, 2 Apr 2022 09:32:19 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500025.china.huawei.com (7.221.188.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 2 Apr 2022 09:33:59 +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; Sat, 2 Apr 2022 09:33:59 +0800 Content-Type: multipart/alternative; boundary="------------IeY0O9FYzEQreYRIrU81euEH" Message-ID: <03d68ba4-0d8f-824b-8c4e-92c9cade6fef@huawei.com> Date: Sat, 2 Apr 2022 09:33:58 +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 v2 2/2] hugetlb: Fix return value of __setup handlers Content-Language: en-US To: David Hildenbrand , , , , , , References: <20220401101232.2790280-1-liupeng256@huawei.com> <20220401101232.2790280-3-liupeng256@huawei.com> <533f85f9-82e2-bfa7-3788-4b2a668daedf@redhat.com> From: "liupeng (DM)" In-Reply-To: <533f85f9-82e2-bfa7-3788-4b2a668daedf@redhat.com> X-Originating-IP: [10.174.179.19] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B2AA4A0026 X-Stat-Signature: 9ig33r5rn3c3h73necgsf1di499nfo1m Authentication-Results: imf15.hostedemail.com; dkim=none; spf=pass (imf15.hostedemail.com: domain of liupeng256@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liupeng256@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspam-User: X-HE-Tag: 1648863243-330136 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: --------------IeY0O9FYzEQreYRIrU81euEH Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 2022/4/1 18:46, David Hildenbrand wrote: > On 01.04.22 12:12, Peng Liu wrote: >> When __setup() return '0', using invalid option values causes the >> entire kernel boot option string to be reported as Unknown. Hugetlb >> calls __setup() and will return '0' when set invalid parameter >> string. >> >> The following phenomenon is observed: >> cmdline: >> hugepagesz=1Y hugepages=1 >> dmesg: >> HugeTLB: unsupported hugepagesz=1Y >> HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring >> Unknown kernel command line parameters "hugepagesz=1Y hugepages=1" >> >> Since hugetlb will print warn or error information before return for >> invalid parameter string, just use return '1' to avoid print again. >> >> Signed-off-by: Peng Liu >> --- >> mm/hugetlb.c | 18 ++++++++---------- >> 1 file changed, 8 insertions(+), 10 deletions(-) >> >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 9cd746432ca9..6dde34c115c9 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -4131,12 +4131,11 @@ static int __init hugepages_setup(char *s) >> int count; >> unsigned long tmp; >> char *p = s; >> - int ret = 1; > Adding this in #1 to remove it in #2 is a bit sub-optimal IMHO. > For #2, which is not necessary for stable, #1 may be needed for stable, this is why we split #2 into a single patch. --------------IeY0O9FYzEQreYRIrU81euEH Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit


On 2022/4/1 18:46, David Hildenbrand wrote:
On 01.04.22 12:12, Peng Liu wrote:

When __setup() return '0', using invalid option values causes the
entire kernel boot option string to be reported as Unknown. Hugetlb
calls __setup() and will return '0' when set invalid parameter
string.

The following phenomenon is observed:
 cmdline:
  hugepagesz=1Y hugepages=1
 dmesg:
  HugeTLB: unsupported hugepagesz=1Y
  HugeTLB: hugepages=1 does not follow a valid hugepagesz, ignoring
  Unknown kernel command line parameters "hugepagesz=1Y hugepages=1"

Since hugetlb will print warn or error information before return for
invalid parameter string, just use return '1' to avoid print again.

Signed-off-by: Peng Liu <liupeng256@huawei.com>
---
 mm/hugetlb.c | 18 ++++++++----------
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9cd746432ca9..6dde34c115c9 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4131,12 +4131,11 @@ static int __init hugepages_setup(char *s)
 	int count;
 	unsigned long tmp;
 	char *p = s;
-	int ret = 1;

Adding this in #1 to remove it in #2 is a bit sub-optimal IMHO.


For #2, which is not necessary for stable, #1 may be needed for
stable, this is why we split #2 into a single patch.
--------------IeY0O9FYzEQreYRIrU81euEH--