Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2462183imb; Mon, 4 Mar 2019 05:54:44 -0800 (PST) X-Google-Smtp-Source: APXvYqw48hVmUwm32eRjZsmB0lTHiLbXU1SMkCshqm0dys7fMUurpSG0Rl8RMyKY83VKVcxrrKDX X-Received: by 2002:a63:1044:: with SMTP id 4mr18690806pgq.324.1551707684807; Mon, 04 Mar 2019 05:54:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551707684; cv=none; d=google.com; s=arc-20160816; b=SlXKGe95w4UXbGMS7whbjsOexDeD49sScqBfJIv+TtPdG77/V8dOs2k06BAdL6Ai+N 5v97pgFdES/r49Oyze0hA34n++tcLFjv/ruu39gLrvbkbctzNY5gZR8U81O3mw/NFOyw iRj+n7Lzyj3lK07RyDY4IIZ5s4HIcr4Sj4Eoc3oBLk5utYI93eCP0riz48wQn/5uHWHP B8Bze1gdIShwbNjd22nGQZ4VofctzIxNg+YBkmV5Iwr818kn3YjwDwOUPRgP57exzFmI p+L1jrNLytU6WVFEnycwvau4ALjHAOFmrmAhVZXY502TrAI5RdWeM2HbU1WuUDzPiLSO ieqg== 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=9l3RGCTTjmJbph6q/td2aX3wHDvyI8VFS91Jhy8HNiM=; b=RFKWlZs4iTKzlvvN/4D4wunv9xeCxTfnzeaUx/6tlgBeDoyNon4xMNjxIiQZ/jdaOV 26Dwp1OEEI3EaH7J41bLUggEu+lztvbuRvwJXwVPMyzLzzsM1haxj7nHo/2ljeedkU6x L1iX2O0XB1+BBmJl4W2urbf2Rx+tkJCR639Zn8Zz7gErEEbwybGGiwkxHOm3iY0r0MhC g0RTKnQXn56djYm/fU7jGWbjGMhE4wEfQoALEXxkkO1KrsEOCq/dQe85XnwKuzpd210w qSJ4i5ix5fslyS5A9sqljCSIJ57c5EDImyfzUFflDJwsaN3d8rgmvgtZuBpvm1jofmuX YQwA== 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 q72si237473pfa.163.2019.03.04.05.54.29; Mon, 04 Mar 2019 05:54: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 S1726850AbfCDNsO (ORCPT + 99 others); Mon, 4 Mar 2019 08:48:14 -0500 Received: from charybdis-ext.suse.de ([195.135.221.2]:59719 "EHLO suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726243AbfCDNsN (ORCPT ); Mon, 4 Mar 2019 08:48:13 -0500 Received: by suse.de (Postfix, from userid 1000) id 7704E446F; Mon, 4 Mar 2019 14:48:12 +0100 (CET) Date: Mon, 4 Mar 2019 14:48:12 +0100 From: Oscar Salvador To: Mike Kravetz Cc: Andrew Morton , David Rientjes , Jing Xiangfeng , mhocko@kernel.org, hughd@google.com, linux-mm@kvack.org, n-horiguchi@ah.jp.nec.com, Andrea Arcangeli , kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] mm/hugetlb: Fix unsigned overflow in __nr_hugepages_store_common() Message-ID: <20190304134809.2aprjskb6z6gv6c5@d104.suse.de> References: <388cbbf5-7086-1d04-4c49-049021504b9d@oracle.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <086c4a4b-a37d-f144-00c0-d9a4062cc5fe@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 Tue, Feb 26, 2019 at 04:03:23PM -0800, Mike Kravetz wrote: > I was just going to update the comments and send you a new patch, but > but your comment got me thinking about this situation. I did not really > change the way this code operates. As a reminder, the original code is like: > > NODEMASK_ALLOC(nodemask_t, nodes_allowed, GFP_KERNEL | __GFP_NORETRY); > > if (nid == NUMA_NO_NODE) { > /* do something */ > } else if (nodes_allowed) { > /* do something else */ > } else { > nodes_allowed = &node_states[N_MEMORY]; > } > > So, the only way we get to that final else if if we can not allocate > a node mask (kmalloc a few words). Right? I wonder why we should > even try to continue in this case. Why not just return right there? > > The specified count value is either a request to increase number of > huge pages or decrease. If we can't allocate a few words, we certainly > are not going to find memory to create huge pages. There 'might' be > surplus pages which can be converted to permanent pages. But remember > this is a 'node specific' request and we can't allocate a mask to pass > down to the conversion routines. So, chances are good we would operate > on the wrong node. The same goes for a request to 'free' huge pages. > Since, we can't allocate a node mask we are likely to free them from > the wrong node. > > Unless my reasoning above is incorrect, I think that final else block > in __nr_hugepages_store_common() is wrong. > > Any additional thoughts? Could not we kill the NODEMASK_ALLOC there? __nr_hugepages_store_common() should be called from a rather shallow stack, and unless I am wrong, the maximum value we can get for a nodemask_t is 128bytes (1024 NUMA nodes). -- Oscar Salvador SUSE L3