linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alastair D'Silva" <alastair@d-silva.org>
To: "'David Hildenbrand'" <david@redhat.com>,
	"'Alastair D'Silva'" <alastair@au1.ibm.com>
Cc: "'Andrew Morton'" <akpm@linux-foundation.org>,
	"'Oscar Salvador'" <osalvador@suse.com>,
	"'Michal Hocko'" <mhocko@suse.com>,
	"'Pavel Tatashin'" <pasha.tatashin@soleen.com>,
	"'Wei Yang'" <richard.weiyang@gmail.com>,
	"'Dan Williams'" <dan.j.williams@intel.com>,
	"'Qian Cai'" <cai@lca.pw>, "'Jason Gunthorpe'" <jgg@ziepe.ca>,
	"'Logan Gunthorpe'" <logang@deltatee.com>,
	"'Ira Weiny'" <ira.weiny@intel.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/2] memory_hotplug: Add a bounds check to check_hotplug_memory_range()
Date: Tue, 10 Sep 2019 20:26:50 +1000	[thread overview]
Message-ID: <05b101d567c2$420492d0$c60db870$@d-silva.org> (raw)
In-Reply-To: <f2cde731-30a8-04ca-0ec6-f654d48db7bc@redhat.com>

> -----Original Message-----
> From: David Hildenbrand <david@redhat.com>
> Sent: Tuesday, 10 September 2019 5:46 PM
> To: Alastair D'Silva <alastair@au1.ibm.com>; alastair@d-silva.org
> Cc: Andrew Morton <akpm@linux-foundation.org>; Oscar Salvador
> <osalvador@suse.com>; Michal Hocko <mhocko@suse.com>; Pavel Tatashin
> <pasha.tatashin@soleen.com>; Wei Yang <richard.weiyang@gmail.com>;
> Dan Williams <dan.j.williams@intel.com>; Qian Cai <cai@lca.pw>; Jason
> Gunthorpe <jgg@ziepe.ca>; Logan Gunthorpe <logang@deltatee.com>; Ira
> Weiny <ira.weiny@intel.com>; linux-mm@kvack.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] memory_hotplug: Add a bounds check to
> check_hotplug_memory_range()
> 
> On 10.09.19 04:52, Alastair D'Silva wrote:
> > From: Alastair D'Silva <alastair@d-silva.org>
> >
> > 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").
> >
> > Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> > ---
> >  include/linux/memory_hotplug.h |  1 +
> >  mm/memory_hotplug.c            | 19 ++++++++++++++++++-
> >  2 files changed, 19 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..3c5428b014f9 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1030,6 +1030,23 @@ int try_online_node(int nid)
> >  	return ret;
> >  }
> >
> > +#ifndef MAX_POSSIBLE_PHYSMEM_BITS
> > +#ifdef MAX_PHYSMEM_BITS
> > +#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS #endif
> #endif
> > +
> 
> I think using MAX_POSSIBLE_PHYSMEM_BITS bits is wrong. You should use
> MAX_PHYSMEM_BITS.
> 
> E.g. on x86_64, MAX_POSSIBLE_PHYSMEM_BITS is 52, while
> MAX_PHYSMEM_BITS is (pgtable_l5_enabled() ? 52 : 46) - so
> MAX_PHYSMEM_BITS depends on the actual HW.
> 

Thanks, I was following the pattern from zsmalloc.c, but what you say makes sense.

> > +int check_hotplug_memory_addressable(u64 start, u64 size) { #ifdef
> > +MAX_POSSIBLE_PHYSMEM_BITS
> > +	if ((start + size - 1) >> MAX_POSSIBLE_PHYSMEM_BITS)
> > +		return -E2BIG;
> > +#endif
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(check_hotplug_memory_addressable);
> > +
> >  static int check_hotplug_memory_range(u64 start, u64 size)  {
> >  	/* memory range must be block size aligned */ @@ -1040,7 +1057,7
> @@
> > static int check_hotplug_memory_range(u64 start, u64 size)
> >  		return -EINVAL;
> >  	}
> >
> > -	return 0;
> > +	return check_hotplug_memory_addressable(start, size);
> >  }
> >
> >  static int online_memory_block(struct memory_block *mem, void *arg)
> >
> 
> 
> --
> 
> Thanks,
> 
> David / dhildenb
> 


-- 
Alastair D'Silva           mob: 0423 762 819
skype: alastair_dsilva     msn: alastair@d-silva.org
blog: http://alastair.d-silva.org    Twitter: @EvilDeece


  reply	other threads:[~2019-09-10 10:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-10  2:52 [PATCH 0/2] Add bounds check for Hotplugged memory Alastair D'Silva
2019-09-10  2:52 ` [PATCH 1/2] memory_hotplug: Add a bounds check to check_hotplug_memory_range() Alastair D'Silva
2019-09-10  7:45   ` David Hildenbrand
2019-09-10 10:26     ` Alastair D'Silva [this message]
2019-09-10  7:45   ` David Hildenbrand
2019-09-10 10:15   ` Kirill A. Shutemov
2019-09-10 10:28     ` Alastair D'Silva
2019-09-10  2:52 ` [PATCH 2/2] mm: Add a bounds check in devm_memremap_pages() Alastair D'Silva
2019-09-10  7:38   ` David Hildenbrand
2019-09-10 10:24     ` Alastair D'Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='05b101d567c2$420492d0$c60db870$@d-silva.org' \
    --to=alastair@d-silva.org \
    --cc=akpm@linux-foundation.org \
    --cc=alastair@au1.ibm.com \
    --cc=cai@lca.pw \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=ira.weiny@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=richard.weiyang@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).