Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp823100ybn; Tue, 24 Sep 2019 10:02:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqxGJLeEv/zFVHcbekNEPFLq3uzPSjMwbEzLjoQrTTj1hhCu/8ssXMbGH+yYY5y2vcwLBCT7 X-Received: by 2002:a2e:7d0d:: with SMTP id y13mr2691397ljc.170.1569344576792; Tue, 24 Sep 2019 10:02:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569344576; cv=none; d=google.com; s=arc-20160816; b=DV381Q3V21oRaoOndEXhS94vpcMK7uu5dQag53BL8VmYaGOU+5juTLQQOcSdKSY0FE wLY1SEP/MeKQRMftGJ3/FW9+y5gAeQ0FGmtkUjBcr7O/DWMmvVlnR3cIyEGZ5hUchvr4 ADsP93N555vwB89cBh9IdOLNqlo21YZzraQDqkVm8fCKI7y8D+Qz7bArpvDbtumGQcYM 83e8/Dr1qwrlKUHGnnH6KQ1Bew1iIXTxCPUYlOuNH/PuZW2K/QvFT/NYj9Tgs8tWwLrR aKL5NZ3mA9JqaYRtfgnwrAfbtpl4AQZ2no+bfIbrz/aSbyzn1LHdIjCLd+M5FYZfcqq4 GblQ== 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=/OfDg+erOJdNugFQiGhfMInvoimLKNnpM8WQ9GYwVsY=; b=qpPV4dX5QsOr8PB/rsD1AilEZJL56F10oUvO0F+NzAONdq18fg61G+PFYCD9epqmPX MYvLFO5uyd+Ti86NYHlOdwAKbKK0ezgtIXWH2aid9VDS7SgfWPpPinE/WsUP3aVVWNrq MfELrLKnGLCZsy8DkW2Lvcjjbnu+lEZAUH+DF2k3xepyRbMA6Dvf4tvmUD4ATLFlKrce gHj7hHy2k6ASY+LMf68d2Xz8dG6mxIJ16dZO4Ox49dYFDKoYO13dahpiHbFbEsDZIkOM i2yV4lvoTDq1yZQhGYYlHLvBIN34fT7nmh+FgHv4GeTUCJIjJlwBT7ZpnEYFGxoGPMMR /b8w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g8si1457514eda.105.2019.09.24.10.02.33; Tue, 24 Sep 2019 10:02:56 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732262AbfIWMZR (ORCPT + 99 others); Mon, 23 Sep 2019 08:25:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:48890 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730431AbfIWMZR (ORCPT ); Mon, 23 Sep 2019 08:25:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A54DEAEAE; Mon, 23 Sep 2019 12:25:14 +0000 (UTC) Date: Mon, 23 Sep 2019 14:25:13 +0200 From: Michal Hocko To: Alastair D'Silva Cc: alastair@d-silva.org, Andrew Morton , David Hildenbrand , Oscar Salvador , Pavel Tatashin , Dan Williams , Wei Yang , Qian Cai , Jason Gunthorpe , Logan Gunthorpe , Ira Weiny , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/2] memory_hotplug: Add a bounds check to check_hotplug_memory_range() Message-ID: <20190923122513.GO6016@dhcp22.suse.cz> References: <20190917010752.28395-1-alastair@au1.ibm.com> <20190917010752.28395-2-alastair@au1.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190917010752.28395-2-alastair@au1.ibm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 17-09-19 11:07:47, Alastair D'Silva wrote: > From: Alastair D'Silva > > On PowerPC, the address ranges allocated to OpenCAPI LPC memory > are allocated from firmware. These address ranges may be higher > than what older kernels permit, as we increased the maximum > permissable address in commit 4ffe713b7587 > ("powerpc/mm: Increase the max addressable memory to 2PB"). It is > possible that the addressable range may change again in the > future. > > In this scenario, we end up with a bogus section returned from > __section_nr (see the discussion on the thread "mm: Trigger bug on > if a section is not found in __section_nr"). > > Adding a check here means that we fail early and have an > opportunity to handle the error gracefully, rather than rumbling > on and potentially accessing an incorrect section. > > Further discussion is also on the thread ("powerpc: Perform a bounds > check in arch_add_memory"). It would be nicer to refer to this by a message-id based url. E.g. http://lkml.kernel.org/r/20190827052047.31547-1-alastair@au1.ibm.com > Signed-off-by: Alastair D'Silva > --- > include/linux/memory_hotplug.h | 1 + > mm/memory_hotplug.c | 13 ++++++++++++- > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h > index f46ea71b4ffd..bc477e98a310 100644 > --- a/include/linux/memory_hotplug.h > +++ b/include/linux/memory_hotplug.h > @@ -110,6 +110,7 @@ extern void __online_page_increment_counters(struct page *page); > extern void __online_page_free(struct page *page); > > extern int try_online_node(int nid); > +int check_hotplug_memory_addressable(u64 start, u64 size); > > extern int arch_add_memory(int nid, u64 start, u64 size, > struct mhp_restrictions *restrictions); > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c73f09913165..02cb9a74f561 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1030,6 +1030,17 @@ int try_online_node(int nid) > return ret; > } > > +int check_hotplug_memory_addressable(u64 start, u64 size) > +{ > +#ifdef MAX_PHYSMEM_BITS > + if ((start + size - 1) >> MAX_PHYSMEM_BITS) > + return -E2BIG; > +#endif Is there any arch which doesn't define this? We seemed to be using this in sparsemem code without any ifdefs. > + > + return 0; > +} > +EXPORT_SYMBOL_GPL(check_hotplug_memory_addressable); If you squashed the patch 2 then it would become clear why this needs to be exported because you would have a driver user. I find it a bit unfortunate to expect that any driver which uses the hotplug code is expected to know that this check should be called. This sounds too error prone. Why hasn't been this done at __add_pages layer? > + > static int check_hotplug_memory_range(u64 start, u64 size) > { > /* memory range must be block size aligned */ > @@ -1040,7 +1051,7 @@ static int check_hotplug_memory_range(u64 start, u64 size) > return -EINVAL; > } > > - return 0; > + return check_hotplug_memory_addressable(start, size); This will result in a silent failure (unlike misaligned case). Is this what we want? > } > > static int online_memory_block(struct memory_block *mem, void *arg) > -- > 2.21.0 > -- Michal Hocko SUSE Labs