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 D42D0C433F5 for ; Wed, 13 Apr 2022 22:04:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EB886B0072; Wed, 13 Apr 2022 18:04:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29BA36B0073; Wed, 13 Apr 2022 18:04:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 164676B0074; Wed, 13 Apr 2022 18:04:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 0340C6B0072 for ; Wed, 13 Apr 2022 18:04:29 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C386A20517 for ; Wed, 13 Apr 2022 22:04:28 +0000 (UTC) X-FDA: 79353235416.08.4C897C5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 2CEE04000B for ; Wed, 13 Apr 2022 22:04:28 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3B87961F62; Wed, 13 Apr 2022 22:04:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4867FC385A7; Wed, 13 Apr 2022 22:04:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1649887466; bh=M42UimkzXE80vxa1qAP02iT+NFCIF1EgvaR5EBI4QG8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=DVPonsQGL6eZmLwgmK7QOXsztBWhzECZLJmherYwMvcFRR1P0ErsfadtB2nWNhyPf RYaEV9p0ldaZViiw+r1+gKmctMi4Of7bgc5/nJfL9anwjojKx+Zg93USQyxU4tReQS cLheyrmwdz9ezfPE7k/RpZp3MC1XOcGae4BaQqgw= Date: Wed, 13 Apr 2022 15:04:22 -0700 From: Andrew Morton To: "liupeng (DM)" Cc: , , , , , , , Subject: Re: [PATCH v3 1/4] hugetlb: Fix wrong use of nr_online_nodes Message-Id: <20220413150422.e4fc3bda48a285bf7bdc5587@linux-foundation.org> In-Reply-To: <692ee24c-a705-0c54-7cad-a9ecf49a8f15@huawei.com> References: <20220413032915.251254-1-liupeng256@huawei.com> <20220413032915.251254-2-liupeng256@huawei.com> <20220412214238.84c20437a052458f6967e9fd@linux-foundation.org> <692ee24c-a705-0c54-7cad-a9ecf49a8f15@huawei.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: oc75qxep1a4o7o5hw69i5wiycxhdrujo Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=DVPonsQG; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2CEE04000B X-HE-Tag: 1649887468-670461 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 Wed, 13 Apr 2022 14:27:54 +0800 "liupeng (DM)" wrote: > > On 2022/4/13 12:42, Andrew Morton wrote: > > On Wed, 13 Apr 2022 03:29:12 +0000 Peng Liu wrote: > > > >> Certain systems are designed to have sparse/discontiguous nodes. In > >> this case, nr_online_nodes can not be used to walk through numa node. > >> Also, a valid node may be greater than nr_online_nodes. > >> > >> However, in hugetlb, it is assumed that nodes are contiguous. Recheck > >> all the places that use nr_online_nodes, and repair them one by one. > >> > > What are the runtime effects of this shortcoming? > > . > > For sparse/discontiguous nodes, the current code may treat a valid node > as invalid, and will fail to allocate all hugepages on a valid node that > "nid >= nr_online_nodes". > > As David suggested: > if (tmp >= nr_online_nodes) > goto invalid; > > Just imagine node 0 and node 2 are online, and node 1 is offline. Assuming > that "node < 2" is valid is wrong. So do you think we should backport thtis fix into earlier kernel releases?