Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp3966321imb; Wed, 6 Mar 2019 01:50:44 -0800 (PST) X-Google-Smtp-Source: APXvYqzo2azhe/b5Vt/v1MG3EwK4128Qr91e34HNRiPLvzoFWmnNzakAqlHVVgaj9UBOJor5J6o8 X-Received: by 2002:a65:51c3:: with SMTP id i3mr5423068pgq.45.1551865844780; Wed, 06 Mar 2019 01:50:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551865844; cv=none; d=google.com; s=arc-20160816; b=XNM7v8t0uEnUO0LnWEymmvdCLWKUhmd31IyRhcseKvlmZzeGCiHVtGxA2K7YkKBbb7 F48jg41V2XfW3U1hN/YeEgWf9R1EhM8pA/AxPQr7B835EtygJEDwEzM7YYQvqHC7A4x/ 7aEGnNNPBie2oyWCY9MqAzQfmgZVpxeldWoPqiEyz6flxAQhgZyQJXafgcR/j88RPtU/ rV/q37yE31+96s2EICsebKl7wSeWId32fQ/y04k8NCJ7oV4KmZN+xfpYIhat4KmSk+pc 4Xw5U+lw5fp7j/ND9CAloIxPvZMBqF5cTIHg9/EYcUjzQETD7fOJnNbY60VvMTb//AwY n3bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=z+KCFvi482qs3sMlCDVL0O5iW/1W++W9hvXvifDSHk4=; b=c+txKa4ADcLZ4tmVFEvIo1/KtliRQ8L1pxO7t+k97H+/8Blk9fxFIOyQ0xjlx3QfUK Cj9qVwNvsxBECjbjBtvHAC5AuGTO8MmyUiDNioqyhc9elHyS260oZ8XTAWL7XdjtvTPd 7pfGjXhXYw0HBdFW0kLTurqVaiMdUjdT2aabeF4HT51eMfpcfdaDEwfpZd2haM8+XPMW 5uu0ziUHyZpa6mfsf4+PS63pTIaE4aY0rwXKn3/yxRY+zLbW50irGKavdjqzIHTWiRD5 K0nacZKO8c1TBWVWplSJWDDTZboh8j8qr5F4DQNDLNMjMFsrZzXYhm7+xcuvYpRpkHfg In6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j29si1053708pgi.449.2019.03.06.01.50.29; Wed, 06 Mar 2019 01:50:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729529AbfCFJlg (ORCPT + 99 others); Wed, 6 Mar 2019 04:41:36 -0500 Received: from charybdis-ext.suse.de ([195.135.221.2]:7170 "EHLO suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726596AbfCFJlg (ORCPT ); Wed, 6 Mar 2019 04:41:36 -0500 Received: by suse.de (Postfix, from userid 1000) id A3FDF44A0; Wed, 6 Mar 2019 10:41:34 +0100 (CET) Date: Wed, 6 Mar 2019 10:41:34 +0100 From: Oscar Salvador To: Mike Kravetz Cc: Naoya Horiguchi , Andrew Morton , David Rientjes , Jing Xiangfeng , "mhocko@kernel.org" , "hughd@google.com" , "linux-mm@kvack.org" , Andrea Arcangeli , "kirill.shutemov@linux.intel.com" , linux-kernel@vger.kernel.org, Alexandre Ghiti Subject: Re: [PATCH v4] mm/hugetlb: Fix unsigned overflow in __nr_hugepages_store_common() Message-ID: <20190306094130.q5v7qfgbekatnmyk@d104.suse.de> References: <8c167be7-06fa-a8c0-8ee7-0bfad41eaba2@oracle.com> <13400ee2-3d3b-e5d6-2d78-a770820417de@oracle.com> <5C74A2DA.1030304@huawei.com> <20190226143620.c6af15c7c897d3362b191e36@linux-foundation.org> <086c4a4b-a37d-f144-00c0-d9a4062cc5fe@oracle.com> <20190305000402.GA4698@hori.linux.bs1.fc.nec.co.jp> <8f3aede3-c07e-ac15-1577-7667e5b70d2f@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f3aede3-c07e-ac15-1577-7667e5b70d2f@oracle.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 04, 2019 at 08:15:40PM -0800, Mike Kravetz wrote: > In addition, the code in __nr_hugepages_store_common() which tries to > handle the case of not being able to allocate a node mask would likely > result in incorrect behavior. Luckily, it is very unlikely we will > ever take this path. If we do, simply return ENOMEM. Hi Mike, I still thnk that we could just get rid of the NODEMASK_ALLOC machinery here, it adds a needlessly complexity IMHO. Note that before "(5df66d306ec9: mm: fix comment for NODEMASK_ALLOC)", the comment about the size was wrong, showing a much bigger size that it actually was, and I would not be surprised if people started to add NODEMASK_ALLOC here and there because of that. Actually, there was a little talk about removing NODEMASK_ALLOC altogether, but some further checks must be done before. > Reported-by: Jing Xiangfeng > Signed-off-by: Mike Kravetz But the overall change looks good to me: Reviewed-by: Oscar Salvador > --- > mm/hugetlb.c | 42 +++++++++++++++++++++++++++++++++--------- > 1 file changed, 33 insertions(+), 9 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index c5c4558e4a79..5a190a652cac 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -2274,7 +2274,7 @@ static int adjust_pool_surplus(struct hstate *h, nodemask_t *nodes_allowed, > } > > #define persistent_huge_pages(h) (h->nr_huge_pages - h->surplus_huge_pages) > -static int set_max_huge_pages(struct hstate *h, unsigned long count, > +static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid, > nodemask_t *nodes_allowed) > { > unsigned long min_count, ret; > @@ -2289,6 +2289,28 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, > goto decrease_pool; > } > > + spin_lock(&hugetlb_lock); > + > + /* > + * Check for a node specific request. > + * Changing node specific huge page count may require a corresponding > + * change to the global count. In any case, the passed node mask > + * (nodes_allowed) will restrict alloc/free to the specified node. > + */ > + if (nid != NUMA_NO_NODE) { > + unsigned long old_count = count; > + > + count += h->nr_huge_pages - h->nr_huge_pages_node[nid]; > + /* > + * User may have specified a large count value which caused the > + * above calculation to overflow. In this case, they wanted > + * to allocate as many huge pages as possible. Set count to > + * largest possible value to align with their intention. > + */ > + if (count < old_count) > + count = ULONG_MAX; > + } > + > /* > * Increase the pool size > * First take pages out of surplus state. Then make up the > @@ -2300,7 +2322,6 @@ static int set_max_huge_pages(struct hstate *h, unsigned long count, > * pool might be one hugepage larger than it needs to be, but > * within all the constraints specified by the sysctls. > */ > - spin_lock(&hugetlb_lock); > while (h->surplus_huge_pages && count > persistent_huge_pages(h)) { > if (!adjust_pool_surplus(h, nodes_allowed, -1)) > break; > @@ -2421,16 +2442,19 @@ static ssize_t __nr_hugepages_store_common(bool obey_mempolicy, > nodes_allowed = &node_states[N_MEMORY]; > } > } else if (nodes_allowed) { > + /* Node specific request */ > + init_nodemask_of_node(nodes_allowed, nid); > + } else { > /* > - * per node hstate attribute: adjust count to global, > - * but restrict alloc/free to the specified node. > + * Node specific request, but we could not allocate the few > + * words required for a node mask. We are unlikely to hit > + * this condition. Since we can not pass down the appropriate > + * node mask, just return ENOMEM. > */ > - count += h->nr_huge_pages - h->nr_huge_pages_node[nid]; > - init_nodemask_of_node(nodes_allowed, nid); > - } else > - nodes_allowed = &node_states[N_MEMORY]; > + return -ENOMEM; > + } > > - err = set_max_huge_pages(h, count, nodes_allowed); > + err = set_max_huge_pages(h, count, nid, nodes_allowed); > if (err) > goto out; > > -- > 2.17.2 > -- Oscar Salvador SUSE L3