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 2E568C433F5 for ; Thu, 10 Feb 2022 03:22:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBF746B0074; Wed, 9 Feb 2022 22:22:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B6CCB6B0075; Wed, 9 Feb 2022 22:22:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5C976B007B; Wed, 9 Feb 2022 22:22:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 985B16B0074 for ; Wed, 9 Feb 2022 22:22:38 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5BCBF97907 for ; Thu, 10 Feb 2022 03:22:38 +0000 (UTC) X-FDA: 79125422796.27.DB31657 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf18.hostedemail.com (Postfix) with ESMTP id 7193F1C0004 for ; Thu, 10 Feb 2022 03:22:37 +0000 (UTC) Received: from kwepemi500007.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4JvMV23K00zccjp; Thu, 10 Feb 2022 11:21:30 +0800 (CST) Received: from kwepemm600012.china.huawei.com (7.193.23.74) by kwepemi500007.china.huawei.com (7.221.188.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Feb 2022 11:22:31 +0800 Received: from huawei.com (10.174.177.28) by kwepemm600012.china.huawei.com (7.193.23.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Feb 2022 11:22:30 +0800 From: liuyuntao To: CC: , , , , , , , Subject: Re: [PATCH] hugetlbfs: fix a truncation issue in hugepages parameter Date: Thu, 10 Feb 2022 11:22:26 +0800 Message-ID: <20220210032226.9043-1-liuyuntao10@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <95d1dc4e-fc3b-fe3c-5d85-218a7410e966@oracle.com> References: <95d1dc4e-fc3b-fe3c-5d85-218a7410e966@oracle.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.174.177.28] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600012.china.huawei.com (7.193.23.74) X-CFilter-Loop: Reflected Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf18.hostedemail.com: domain of liuyuntao10@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liuyuntao10@huawei.com X-Rspamd-Server: rspam03 X-Rspam-User: X-Stat-Signature: nz6bw888u63es5shbywcrm6xhu1ban3n X-Rspamd-Queue-Id: 7193F1C0004 X-HE-Tag: 1644463357-660314 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-02-10 0:43 UTC, Mike Kravetz wrote: > On 2/9/22 05:40, liuyuntao wrote: > > From: Liu Yuntao > >=20 > > When we specify a large number for node in hugepages parameter, > > it may be parsed to another number due to truncation in this statemen= t: > > node =3D tmp; > >=20 > > For example, add following parameter in command line: > > hugepagesz=3D1G hugepages=3D4294967297:5 > > and kernel will allocate 5 hugepages for node 1 instead of ignoring i= t. > >=20 > > I move the validation check earlier to fix this issue, and slightly > > simplifies the condition here. > >=20 > > Fixes: b5389086ad7be0 ("hugetlbfs: extend the definition of hugepages= parameter to support node allocation") > > Signed-off-by: Liu Yuntao > > --- > > mm/hugetlb.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > >=20 > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 61895cc01d09..0929547f6ad6 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -4159,10 +4159,10 @@ static int __init hugepages_setup(char *s) > > pr_warn("HugeTLB: architecture can't support node specific alloc= , ignoring!\n"); > > return 0; > > } > > + if (tmp >=3D nr_online_nodes) > > + goto invalid; > > node =3D tmp; >=20 > I am surprised none of the automated checking complained about that > assignment. I think such assignments may be very common in kernel, and thus automated checks just ignore them. >=20 > > p +=3D count + 1; > > - if (node < 0 || node >=3D nr_online_nodes) >=20 > I can't remember, but I think that check for node < 0 was added to hand= le > overflow during the above assignment. Do you remember Zhenguo Yao? No, I don't. I took a look and found that the check for node < 0 has been there since his first version of patch. > =20 > > - goto invalid; > > /* Parse hugepages */ > > if (sscanf(p, "%lu%n", &tmp, &count) !=3D 1) > > goto invalid; >=20 > Thanks, >=20 > Reviewed-by: Mike Kravetz >=20 > --=20 > Mike Kravetz -- Liu Yuntao