[PATCH 2/2] arm64: set MAX_MEMBLOCK_ADDR according to linear region size

Catalin Marinas catalin.marinas at arm.com
Thu Aug 20 02:17:45 PDT 2015


On Thu, Aug 20, 2015 at 07:09:25AM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas at arm.com> wrote:
> > On Tue, Aug 18, 2015 at 12:04:27PM +0200, Ard Biesheuvel wrote:
> >> On 18 August 2015 at 12:00, Will Deacon <will.deacon at arm.com> wrote:
> >> > On Tue, Aug 18, 2015 at 10:34:42AM +0100, Ard Biesheuvel wrote:
> >> >> The linear region size of a 39-bit VA kernel is only 256 GB, which
> >> >> may be insufficient to cover all of system RAM, even on platforms
> >> >> that have much less than 256 GB of memory but which is laid out
> >> >> very sparsely.
> >> >>
> >> >> So make sure we clip the memory we will not be able to map before
> >> >> installing it into the memblock memory table, by setting
> >> >> MAX_MEMBLOCK_ADDR accordingly.
> >> >>
> >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >> >> ---
> >> >>  arch/arm64/include/asm/memory.h | 8 ++++++++
> >> >>  1 file changed, 8 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> >> >> index f800d45ea226..44a59c20e773 100644
> >> >> --- a/arch/arm64/include/asm/memory.h
> >> >> +++ b/arch/arm64/include/asm/memory.h
> >> >> @@ -114,6 +114,14 @@ extern phys_addr_t               memstart_addr;
> >> >>  #define PHYS_OFFSET          ({ memstart_addr; })
> >> >>
> >> >>  /*
> >> >> + * The maximum physical address that the linear direct mapping
> >> >> + * of system RAM can cover. (PAGE_OFFSET can be interpreted as
> >> >> + * a 2's complement signed quantity and negated to derive the
> >> >> + * maximum size of the linear mapping.)
> >> >> + */
> >> >> +#define MAX_MEMBLOCK_ADDR    ({ memstart_addr - PAGE_OFFSET - 1; })
> >> >
> >> > If we initialised memory_limit to this value and changed early_mem to
> >> > use min (i.e. only restrict the limit further), would that avoid the
> >> > need to change the of code? It looks like PPC uses
> >> > memblock_enforce_memory_limit for similar reasons.
> >>
> >> Yes, that would be yet another way of doing things. But since Catalin
> >> explicitly requested that both checks (i.e., bottom end and top end)
> >> occur in the same place, and indicated his preference not to override
> >> early_init_dt_add_memory_arch() if we can avoid it, the only way is to
> >> hack it in there.
> >
> > Talking to Will, we decided to go for a quick fix with cc stable that
> > does something like:
> >
> >         memblock_enforce_memory_limit(min(memory_limit, ~PAGE_OFFSET));
> 
> Actually, this won't work. The function limits the /amount/ of memory,
> and disregards holes when doing so.

Ah, we missed this (but its behaviour makes sense, it's meant for mem=
arguments).

-- 
Catalin



More information about the linux-arm-kernel mailing list