On Tue, 2019-08-27 at 09:13 +0200, David Hildenbrand wrote: > On 27.08.19 08:39, Alastair D'Silva wrote: > > On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote: > > > On Tue 27-08-19 15:20:46, Alastair D'Silva wrote: > > > > From: Alastair D'Silva <alast...@d-silva.org> > > > > > > > > It is possible for firmware to allocate memory ranges outside > > > > the range of physical memory that we support > > > > (MAX_PHYSMEM_BITS). > > > > > > Doesn't that count as a FW bug? Do you have any evidence of that > > > in > > > the > > > field? Just wondering... > > > > > > > Not outside our lab, but OpenCAPI attached LPC memory is assigned > > addresses based on the slot/NPU it is connected to. These addresses > > prior to: > > 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to > > 2PB") > > were inaccessible and resulted in bogus sections - see our > > discussion > > on 'mm: Trigger bug on if a section is not found in __section_nr'. > > Doing this check here was your suggestion :) > > > > It's entirely possible that a similar problem will occur in the > > future, > > and it's cheap to guard against, which is why I've added this. > > > > If you keep it here, I guess this should be wrapped by a > WARN_ON_ONCE(). > > If we move it to common code (e.g., __add_pages() or add_memory()), > then > probably not. I can see that s390x allows to configure > MAX_PHYSMEM_BITS, > so the check could actually make sense. >
I couldn't see a nice platform indepedent way to determine the allowable address range, but if there is, then I'll move this to the generic code instead. -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australia mob: 0423 762 819