[PATCH 0/2] arm64: ignore memory outside of the linear range

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Ard Biesheuvel]

This is a followup to the single patch I posted on Aug 15th to ignore
RAM that cannot be covered by the linear mapping. Instead of clipping
the memory after the fact, this clips the memory before installing the
regions into the memblock memory table.

This is basically the approach that Mark Rutland suggested here

http://article.gmane.org/gmane.linux.ports.arm.kernel/430239

but modified to correctly consider the base of the kernel image as the
start of the linear mapping.

Ard Biesheuvel (2):
  of/fdt: make memblock maximum physical address arch configurable
  arm64: set MAX_MEMBLOCK_ADDR according to linear region size

 arch/arm64/include/asm/memory.h |  8 ++++++++
 drivers/of/fdt.c                | 12 +++++++-----
 2 files changed, 15 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 1/2] of/fdt: make memblock maximum physical address arch configurable

[Ard Biesheuvel]

When parsing the memory nodes to populate the memblock memory
table, we check against high and low limits and clip any memory
that exceeds either one of them.

However, for arm64, the high limit of (phys_addr_t)~0 is not very
meaningful, since phys_addr_t is 64 bits (i.e., no limit) but there
may be other constraints that limit the memory ranges that we can
support.

So rename MAX_PHYS_ADDR to MAX_MEMBLOCK_ADDR (for clarity) and only
define it if the arch does not supply a definition of its own.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 drivers/of/fdt.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 07496560e5b9..6e82bc42373b 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -967,7 +967,9 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
-#define MAX_PHYS_ADDR	((phys_addr_t)~0)
+#ifndef MAX_MEMBLOCK_ADDR
+#define MAX_MEMBLOCK_ADDR	((phys_addr_t)~0)
+#endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
@@ -984,16 +986,16 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 	}
 	size &= PAGE_MASK;
 
-	if (base > MAX_PHYS_ADDR) {
+	if (base > MAX_MEMBLOCK_ADDR) {
 		pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
 				base, base + size);
 		return;
 	}
 
-	if (base + size - 1 > MAX_PHYS_ADDR) {
+	if (base + size - 1 > MAX_MEMBLOCK_ADDR) {
 		pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
-				((u64)MAX_PHYS_ADDR) + 1, base + size);
-		size = MAX_PHYS_ADDR - base + 1;
+				((u64)MAX_MEMBLOCK_ADDR) + 1, base + size);
+		size = MAX_MEMBLOCK_ADDR - base + 1;
 	}
 
 	if (base + size < phys_offset) {
-- 
1.9.1

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

[Ard Biesheuvel]

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@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; })
+
+/*
  * PFNs are used to describe any physical page; this means
  * PFN 0 == physical address 0.
  *
-- 
1.9.1

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

[Will Deacon]

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@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.

Will

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

[Ard Biesheuvel]

On 18 August 2015 at 12:00, Will Deacon <will.deacon@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@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.

-- 
Ard.

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Stuart Yoder]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: Tuesday, August 18, 2015 4:35 AM
> To: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com; catalin.marinas at arm.com; robh at kernel.org
> Cc: grant.likely at linaro.org; Yoder Stuart-B08248; will.deacon at arm.com; Ard Biesheuvel
> Subject: [PATCH 0/2] arm64: ignore memory outside of the linear range
> 
> This is a followup to the single patch I posted on Aug 15th to ignore
> RAM that cannot be covered by the linear mapping. Instead of clipping
> the memory after the fact, this clips the memory before installing the
> regions into the memblock memory table.
> 
> This is basically the approach that Mark Rutland suggested here
> 
> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
> 
> but modified to correctly consider the base of the kernel image as the
> start of the linear mapping.
> 
> Ard Biesheuvel (2):
>   of/fdt: make memblock maximum physical address arch configurable
>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
> 
>  arch/arm64/include/asm/memory.h |  8 ++++++++
>  drivers/of/fdt.c                | 12 +++++++-----
>  2 files changed, 15 insertions(+), 5 deletions(-)

Tested on Freescale LS2085ARDB which has a split memory region
that triggers the bug.

Tested-by: Stuart Yoder <stuart.yoder@freescale.com>

Thanks,
Stuart

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

[Catalin Marinas]

On Tue, Aug 18, 2015 at 11:00:27AM +0100, Will Deacon 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@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; })

With the current memory layout, this could also be __pa(~0UL). I guess
we could solve this with a single patch, though I'm not sure whether we
break other architectures:

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 07496560e5b9..ff8a885d5ff0 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -967,7 +967,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
-#define MAX_PHYS_ADDR	((phys_addr_t)~0)
+#define MAX_PHYS_ADDR	(__pa(~0UL))
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {

> 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?

Only that we can't initialise memory_limit statically since
memstart_addr is not constant. We would need to do this somewhere before
early_mem() is run (in setup_machine_fdt or immediately after it).

My point to Ard was that since we already do a sanity check on the
memblocks in early_init_dt_add_memory_arch() and ignore those below
PHYS_OFFSET, it makes sense to reuse the same function since it already
has all the logic in place and corresponding warnings. With a later
memblock limiting we would have to add extra printing to inform the
user.

-- 
Catalin

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

[Ard Biesheuvel]

On 18 August 2015 at 16:24, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Aug 18, 2015 at 11:00:27AM +0100, Will Deacon 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@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; })
>
> With the current memory layout, this could also be __pa(~0UL). I guess
> we could solve this with a single patch, though I'm not sure whether we
> break other architectures:
>

Every 32-bit DT arch with highmem, quite likely.


> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 07496560e5b9..ff8a885d5ff0 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -967,7 +967,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  }
>
>  #ifdef CONFIG_HAVE_MEMBLOCK
> -#define MAX_PHYS_ADDR  ((phys_addr_t)~0)
> +#define MAX_PHYS_ADDR  (__pa(~0UL))
>
>  void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
>  {
>
>> 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?
>
> Only that we can't initialise memory_limit statically since
> memstart_addr is not constant. We would need to do this somewhere before
> early_mem() is run (in setup_machine_fdt or immediately after it).
>
> My point to Ard was that since we already do a sanity check on the
> memblocks in early_init_dt_add_memory_arch() and ignore those below
> PHYS_OFFSET, it makes sense to reuse the same function since it already
> has all the logic in place and corresponding warnings. With a later
> memblock limiting we would have to add extra printing to inform the
> user.
>
> --
> Catalin

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

[Ard Biesheuvel]

On 18 August 2015 at 16:31, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 18 August 2015 at 16:24, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> On Tue, Aug 18, 2015 at 11:00:27AM +0100, Will Deacon 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@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; })
>>
>> With the current memory layout, this could also be __pa(~0UL). I guess
>> we could solve this with a single patch, though I'm not sure whether we
>> break other architectures:
>>
>
> Every 32-bit DT arch with highmem, quite likely.
>

I mean (L)PAE, of course

>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 07496560e5b9..ff8a885d5ff0 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -967,7 +967,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>>  }
>>
>>  #ifdef CONFIG_HAVE_MEMBLOCK
>> -#define MAX_PHYS_ADDR  ((phys_addr_t)~0)
>> +#define MAX_PHYS_ADDR  (__pa(~0UL))
>>
>>  void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
>>  {
>>
>>> 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?
>>
>> Only that we can't initialise memory_limit statically since
>> memstart_addr is not constant. We would need to do this somewhere before
>> early_mem() is run (in setup_machine_fdt or immediately after it).
>>
>> My point to Ard was that since we already do a sanity check on the
>> memblocks in early_init_dt_add_memory_arch() and ignore those below
>> PHYS_OFFSET, it makes sense to reuse the same function since it already
>> has all the logic in place and corresponding warnings. With a later
>> memblock limiting we would have to add extra printing to inform the
>> user.
>>
>> --
>> Catalin

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

[Russell King - ARM Linux]

On Tue, Aug 18, 2015 at 03:24:36PM +0100, Catalin Marinas wrote:
> With the current memory layout, this could also be __pa(~0UL). I guess
> we could solve this with a single patch, though I'm not sure whether we
> break other architectures:

No.  __pa() is only valid within the lowmem mapping, not outside of it.
What you'd get for a virtual address of ~0UL is not well defined, so
you should not use this in generic code.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

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

[Catalin Marinas]

On Tue, Aug 18, 2015 at 03:51:49PM +0100, Russell King - ARM Linux wrote:
> On Tue, Aug 18, 2015 at 03:24:36PM +0100, Catalin Marinas wrote:
> > With the current memory layout, this could also be __pa(~0UL). I guess
> > we could solve this with a single patch, though I'm not sure whether we
> > break other architectures:
> 
> No.  __pa() is only valid within the lowmem mapping, not outside of it.
> What you'd get for a virtual address of ~0UL is not well defined, so
> you should not use this in generic code.

You are right. We'll keep this max memblock address in the arch code.

-- 
Catalin

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

[Catalin Marinas]

On Tue, Aug 18, 2015 at 12:04:27PM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 12:00, Will Deacon <will.deacon@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@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));

Afterwards, we should still sort early_init_dt_add_memory_arch() to get
the nicer printing since, as it stands, checking that a u64 is bigger
than ULONG_MAX is pointless on 64-bit.

Thanks.

-- 
Catalin

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

[Ard Biesheuvel]

On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas@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@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@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));
>

~PAGE_OFFSET + 1 ?

> Afterwards, we should still sort early_init_dt_add_memory_arch() to get
> the nicer printing since, as it stands, checking that a u64 is bigger
> than ULONG_MAX is pointless on 64-bit.
>
> Thanks.
>
> --
> Catalin

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

[Catalin Marinas]

On Tue, Aug 18, 2015 at 07:44:59PM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas@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@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@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));
> 
> ~PAGE_OFFSET + 1 ?

Yes.

-- 
Catalin

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

[Ard Biesheuvel]

On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas@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@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@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.

> Afterwards, we should still sort early_init_dt_add_memory_arch() to get
> the nicer printing since, as it stands, checking that a u64 is bigger
> than ULONG_MAX is pointless on 64-bit.
>
> Thanks.
>
> --
> Catalin

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

[Catalin Marinas]

On Thu, Aug 20, 2015 at 07:09:25AM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 19:39, Catalin Marinas <catalin.marinas@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@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@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

[PATCH 1/2] of/fdt: make memblock maximum physical address arch configurable

[Catalin Marinas]

On Tue, Aug 18, 2015 at 11:34:41AM +0200, Ard Biesheuvel wrote:
> When parsing the memory nodes to populate the memblock memory
> table, we check against high and low limits and clip any memory
> that exceeds either one of them.
> 
> However, for arm64, the high limit of (phys_addr_t)~0 is not very
> meaningful, since phys_addr_t is 64 bits (i.e., no limit) but there
> may be other constraints that limit the memory ranges that we can
> support.
> 
> So rename MAX_PHYS_ADDR to MAX_MEMBLOCK_ADDR (for clarity) and only
> define it if the arch does not supply a definition of its own.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

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

[Catalin Marinas]

On Tue, Aug 18, 2015 at 11:34:42AM +0200, 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@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; })

Would it be easier to understand as just memstart_addr + ~PAGE_OFFSET?

Otherwise:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

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

[Ard Biesheuvel]

> On 20 aug. 2015, at 11:19, Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
>> On Tue, Aug 18, 2015 at 11:34:42AM +0200, 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@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; })
> 
> Would it be easier to understand as just memstart_addr + ~PAGE_OFFSET?
> 

Whichever you prefer

> Otherwise:
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thanks

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

[Catalin Marinas]

On Thu, Aug 20, 2015 at 01:54:40PM +0200, Ard Biesheuvel wrote:
> 
> 
> > On 20 aug. 2015, at 11:19, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > 
> >> On Tue, Aug 18, 2015 at 11:34:42AM +0200, 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@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; })
> > 
> > Would it be easier to understand as just memstart_addr + ~PAGE_OFFSET?
> 
> Whichever you prefer

Just leave it as it is, not sure it's any clearer. Basically the maximum
size we can map is (0 - PAGE_OFFSET), so if we make the range inclusive,
we get to memstart_addr - PAGE_OFFSET - 1.

-- 
Catalin

[PATCH 1/2] of/fdt: make memblock maximum physical address arch configurable

[Rob Herring]

On Tue, Aug 18, 2015 at 4:34 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> When parsing the memory nodes to populate the memblock memory
> table, we check against high and low limits and clip any memory
> that exceeds either one of them.
>
> However, for arm64, the high limit of (phys_addr_t)~0 is not very
> meaningful, since phys_addr_t is 64 bits (i.e., no limit) but there
> may be other constraints that limit the memory ranges that we can
> support.
>
> So rename MAX_PHYS_ADDR to MAX_MEMBLOCK_ADDR (for clarity) and only
> define it if the arch does not supply a definition of its own.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

Acked-by: Rob Herring <robh@kernel.org>

> ---
>  drivers/of/fdt.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 07496560e5b9..6e82bc42373b 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -967,7 +967,9 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  }
>
>  #ifdef CONFIG_HAVE_MEMBLOCK
> -#define MAX_PHYS_ADDR  ((phys_addr_t)~0)
> +#ifndef MAX_MEMBLOCK_ADDR
> +#define MAX_MEMBLOCK_ADDR      ((phys_addr_t)~0)
> +#endif
>
>  void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
>  {
> @@ -984,16 +986,16 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
>         }
>         size &= PAGE_MASK;
>
> -       if (base > MAX_PHYS_ADDR) {
> +       if (base > MAX_MEMBLOCK_ADDR) {
>                 pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
>                                 base, base + size);
>                 return;
>         }
>
> -       if (base + size - 1 > MAX_PHYS_ADDR) {
> +       if (base + size - 1 > MAX_MEMBLOCK_ADDR) {
>                 pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
> -                               ((u64)MAX_PHYS_ADDR) + 1, base + size);
> -               size = MAX_PHYS_ADDR - base + 1;
> +                               ((u64)MAX_MEMBLOCK_ADDR) + 1, base + size);
> +               size = MAX_MEMBLOCK_ADDR - base + 1;
>         }
>
>         if (base + size < phys_offset) {
> --
> 1.9.1
>

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Ard Biesheuvel]

On 18 August 2015 at 16:18, Stuart Yoder <stuart.yoder@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
>> Sent: Tuesday, August 18, 2015 4:35 AM
>> To: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com; catalin.marinas at arm.com; robh at kernel.org
>> Cc: grant.likely at linaro.org; Yoder Stuart-B08248; will.deacon at arm.com; Ard Biesheuvel
>> Subject: [PATCH 0/2] arm64: ignore memory outside of the linear range
>>
>> This is a followup to the single patch I posted on Aug 15th to ignore
>> RAM that cannot be covered by the linear mapping. Instead of clipping
>> the memory after the fact, this clips the memory before installing the
>> regions into the memblock memory table.
>>
>> This is basically the approach that Mark Rutland suggested here
>>
>> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
>>
>> but modified to correctly consider the base of the kernel image as the
>> start of the linear mapping.
>>
>> Ard Biesheuvel (2):
>>   of/fdt: make memblock maximum physical address arch configurable
>>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
>>
>>  arch/arm64/include/asm/memory.h |  8 ++++++++
>>  drivers/of/fdt.c                | 12 +++++++-----
>>  2 files changed, 15 insertions(+), 5 deletions(-)
>
> Tested on Freescale LS2085ARDB which has a split memory region
> that triggers the bug.
>
> Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
>

Hi Will,

Will you be picking up this series for v4.3? If so, do you need me to
resend it with the tags added?

Thanks,
Ard.

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Will Deacon]

On Mon, Aug 24, 2015 at 09:00:43AM +0100, Ard Biesheuvel wrote:
> >> This is a followup to the single patch I posted on Aug 15th to ignore
> >> RAM that cannot be covered by the linear mapping. Instead of clipping
> >> the memory after the fact, this clips the memory before installing the
> >> regions into the memblock memory table.
> >>
> >> This is basically the approach that Mark Rutland suggested here
> >>
> >> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
> >>
> >> but modified to correctly consider the base of the kernel image as the
> >> start of the linear mapping.
> >>
> >> Ard Biesheuvel (2):
> >>   of/fdt: make memblock maximum physical address arch configurable
> >>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
> >>
> >>  arch/arm64/include/asm/memory.h |  8 ++++++++
> >>  drivers/of/fdt.c                | 12 +++++++-----
> >>  2 files changed, 15 insertions(+), 5 deletions(-)
> >
> > Tested on Freescale LS2085ARDB which has a split memory region
> > that triggers the bug.
> >
> > Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
> >
> 
> Will you be picking up this series for v4.3? If so, do you need me to
> resend it with the tags added?

Sorry, I missed Rob's ack on the of/fdt.c change. I'll pick these up
later today, no need to resend.

Cheers,

Will

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Stuart Yoder]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Monday, August 24, 2015 4:23 AM
> To: Ard Biesheuvel
> Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland; Catalin Marinas; robh at kernel.org; Yoder Stuart-B08248
> Subject: Re: [PATCH 0/2] arm64: ignore memory outside of the linear range
> 
> On Mon, Aug 24, 2015 at 09:00:43AM +0100, Ard Biesheuvel wrote:
> > >> This is a followup to the single patch I posted on Aug 15th to ignore
> > >> RAM that cannot be covered by the linear mapping. Instead of clipping
> > >> the memory after the fact, this clips the memory before installing the
> > >> regions into the memblock memory table.
> > >>
> > >> This is basically the approach that Mark Rutland suggested here
> > >>
> > >> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
> > >>
> > >> but modified to correctly consider the base of the kernel image as the
> > >> start of the linear mapping.
> > >>
> > >> Ard Biesheuvel (2):
> > >>   of/fdt: make memblock maximum physical address arch configurable
> > >>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
> > >>
> > >>  arch/arm64/include/asm/memory.h |  8 ++++++++
> > >>  drivers/of/fdt.c                | 12 +++++++-----
> > >>  2 files changed, 15 insertions(+), 5 deletions(-)
> > >
> > > Tested on Freescale LS2085ARDB which has a split memory region
> > > that triggers the bug.
> > >
> > > Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
> > >
> >
> > Will you be picking up this series for v4.3? If so, do you need me to
> > resend it with the tags added?
> 
> Sorry, I missed Rob's ack on the of/fdt.c change. I'll pick these up
> later today, no need to resend.

Are we sending to stable as well?

Stuart

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Will Deacon]

On Mon, Aug 24, 2015 at 02:58:26PM +0100, Stuart Yoder wrote:
> > On Mon, Aug 24, 2015 at 09:00:43AM +0100, Ard Biesheuvel wrote:
> > > >> This is a followup to the single patch I posted on Aug 15th to ignore
> > > >> RAM that cannot be covered by the linear mapping. Instead of clipping
> > > >> the memory after the fact, this clips the memory before installing the
> > > >> regions into the memblock memory table.
> > > >>
> > > >> This is basically the approach that Mark Rutland suggested here
> > > >>
> > > >> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
> > > >>
> > > >> but modified to correctly consider the base of the kernel image as the
> > > >> start of the linear mapping.
> > > >>
> > > >> Ard Biesheuvel (2):
> > > >>   of/fdt: make memblock maximum physical address arch configurable
> > > >>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
> > > >>
> > > >>  arch/arm64/include/asm/memory.h |  8 ++++++++
> > > >>  drivers/of/fdt.c                | 12 +++++++-----
> > > >>  2 files changed, 15 insertions(+), 5 deletions(-)
> > > >
> > > > Tested on Freescale LS2085ARDB which has a split memory region
> > > > that triggers the bug.
> > > >
> > > > Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
> > > >
> > >
> > > Will you be picking up this series for v4.3? If so, do you need me to
> > > resend it with the tags added?
> > 
> > Sorry, I missed Rob's ack on the of/fdt.c change. I'll pick these up
> > later today, no need to resend.
> 
> Are we sending to stable as well?

I've already pushed the patch out without a Cc stable (it's not a
regression afaict), so if you want it backported then you'll need to send
it to stable separately.

Will

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Stuart Yoder]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Monday, August 24, 2015 9:08 AM
> To: Yoder Stuart-B08248
> Cc: Ard Biesheuvel; linux-arm-kernel at lists.infradead.org; Mark Rutland; Catalin Marinas; robh at kernel.org
> Subject: Re: [PATCH 0/2] arm64: ignore memory outside of the linear range
> 
> On Mon, Aug 24, 2015 at 02:58:26PM +0100, Stuart Yoder wrote:
> > > On Mon, Aug 24, 2015 at 09:00:43AM +0100, Ard Biesheuvel wrote:
> > > > >> This is a followup to the single patch I posted on Aug 15th to ignore
> > > > >> RAM that cannot be covered by the linear mapping. Instead of clipping
> > > > >> the memory after the fact, this clips the memory before installing the
> > > > >> regions into the memblock memory table.
> > > > >>
> > > > >> This is basically the approach that Mark Rutland suggested here
> > > > >>
> > > > >> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
> > > > >>
> > > > >> but modified to correctly consider the base of the kernel image as the
> > > > >> start of the linear mapping.
> > > > >>
> > > > >> Ard Biesheuvel (2):
> > > > >>   of/fdt: make memblock maximum physical address arch configurable
> > > > >>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
> > > > >>
> > > > >>  arch/arm64/include/asm/memory.h |  8 ++++++++
> > > > >>  drivers/of/fdt.c                | 12 +++++++-----
> > > > >>  2 files changed, 15 insertions(+), 5 deletions(-)
> > > > >
> > > > > Tested on Freescale LS2085ARDB which has a split memory region
> > > > > that triggers the bug.
> > > > >
> > > > > Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
> > > > >
> > > >
> > > > Will you be picking up this series for v4.3? If so, do you need me to
> > > > resend it with the tags added?
> > >
> > > Sorry, I missed Rob's ack on the of/fdt.c change. I'll pick these up
> > > later today, no need to resend.
> >
> > Are we sending to stable as well?
> 
> I've already pushed the patch out without a Cc stable (it's not a
> regression afaict), so if you want it backported then you'll need to send
> it to stable separately.

Ok, was asking because of Catalin's previous comment:

 > Even though it is not a regression, I think it is a bug fix and it's
 > worth cc'ing stable (though we could push it after 4.3-rc1).

Ard, are you going to send to stable?

Thanks,
Stuart

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Ard Biesheuvel]

On 25 August 2015 at 00:34, Stuart Yoder <stuart.yoder@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: Will Deacon [mailto:will.deacon at arm.com]
>> Sent: Monday, August 24, 2015 9:08 AM
>> To: Yoder Stuart-B08248
>> Cc: Ard Biesheuvel; linux-arm-kernel at lists.infradead.org; Mark Rutland; Catalin Marinas; robh at kernel.org
>> Subject: Re: [PATCH 0/2] arm64: ignore memory outside of the linear range
>>
>> On Mon, Aug 24, 2015 at 02:58:26PM +0100, Stuart Yoder wrote:
>> > > On Mon, Aug 24, 2015 at 09:00:43AM +0100, Ard Biesheuvel wrote:
>> > > > >> This is a followup to the single patch I posted on Aug 15th to ignore
>> > > > >> RAM that cannot be covered by the linear mapping. Instead of clipping
>> > > > >> the memory after the fact, this clips the memory before installing the
>> > > > >> regions into the memblock memory table.
>> > > > >>
>> > > > >> This is basically the approach that Mark Rutland suggested here
>> > > > >>
>> > > > >> http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
>> > > > >>
>> > > > >> but modified to correctly consider the base of the kernel image as the
>> > > > >> start of the linear mapping.
>> > > > >>
>> > > > >> Ard Biesheuvel (2):
>> > > > >>   of/fdt: make memblock maximum physical address arch configurable
>> > > > >>   arm64: set MAX_MEMBLOCK_ADDR according to linear region size
>> > > > >>
>> > > > >>  arch/arm64/include/asm/memory.h |  8 ++++++++
>> > > > >>  drivers/of/fdt.c                | 12 +++++++-----
>> > > > >>  2 files changed, 15 insertions(+), 5 deletions(-)
>> > > > >
>> > > > > Tested on Freescale LS2085ARDB which has a split memory region
>> > > > > that triggers the bug.
>> > > > >
>> > > > > Tested-by: Stuart Yoder <stuart.yoder@freescale.com>
>> > > > >
>> > > >
>> > > > Will you be picking up this series for v4.3? If so, do you need me to
>> > > > resend it with the tags added?
>> > >
>> > > Sorry, I missed Rob's ack on the of/fdt.c change. I'll pick these up
>> > > later today, no need to resend.
>> >
>> > Are we sending to stable as well?
>>
>> I've already pushed the patch out without a Cc stable (it's not a
>> regression afaict), so if you want it backported then you'll need to send
>> it to stable separately.
>
> Ok, was asking because of Catalin's previous comment:
>
>  > Even though it is not a regression, I think it is a bug fix and it's
>  > worth cc'ing stable (though we could push it after 4.3-rc1).
>

Indeed. Catalin also mentioned that you and he discussed a minimal fix
with a cc to stable, only the fix itself was flawed. So let's not make
this Stuart's problem, considering that this issue breaks all arm64
systems with 32+ GB of RAM if they follow ARM's own recommendation
regarding the physical layout of memory.

> Ard, are you going to send to stable?
>

We'll have to wait until the merge window closes, of course, but yes,
we should propose it.

@Will: what do you think? It would be nice to have you on record with
an opinion rather than leaving it up to Stuart.

-- 
Ard.

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Russell King - ARM Linux]

On Tue, Aug 25, 2015 at 11:45:01AM +0200, Ard Biesheuvel wrote:
> On 25 August 2015 at 00:34, Stuart Yoder <stuart.yoder@freescale.com> wrote:
> > Ard, are you going to send to stable?
> >
> 
> We'll have to wait until the merge window closes, of course, but yes,
> we should propose it.

If it's important enough for stable, then it's important enough to go in
at _any_ time, merge window or not.  Fixes are _important_.

https://lwn.net/Articles/608917/

paragraph 3.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Will Deacon]

On Tue, Aug 25, 2015 at 10:45:01AM +0100, Ard Biesheuvel wrote:
> On 25 August 2015 at 00:34, Stuart Yoder <stuart.yoder@freescale.com> wrote:
> >> On Mon, Aug 24, 2015 at 02:58:26PM +0100, Stuart Yoder wrote:
> >> > Are we sending to stable as well?
> >>
> >> I've already pushed the patch out without a Cc stable (it's not a
> >> regression afaict), so if you want it backported then you'll need to send
> >> it to stable separately.
> >
> > Ok, was asking because of Catalin's previous comment:
> >
> >  > Even though it is not a regression, I think it is a bug fix and it's
> >  > worth cc'ing stable (though we could push it after 4.3-rc1).
> >
> 
> Indeed. Catalin also mentioned that you and he discussed a minimal fix
> with a cc to stable, only the fix itself was flawed. So let's not make
> this Stuart's problem, considering that this issue breaks all arm64
> systems with 32+ GB of RAM if they follow ARM's own recommendation
> regarding the physical layout of memory.
> 
> > Ard, are you going to send to stable?
> >
> 
> We'll have to wait until the merge window closes, of course, but yes,
> we should propose it.
> 
> @Will: what do you think? It would be nice to have you on record with
> an opinion rather than leaving it up to Stuart.

This isn't something that has *ever* worked with the arm64 kernel,
right? In which case, it's not a regression, it's more like adding
support for some systems that we've not supported before. Now, given the
nature of the patch, I'm not against stable, but by the time Stuart
pointed that out, I'd already pushed the patch and I don't want to
rebase our 4.3 queue at this stage.

The best bet is to send this to stable once it's in mainline (i.e. -rc1)
and I think it makes sense for Stuart to do that, since he is the one
most interested in having that happen.

Will

[PATCH 0/2] arm64: ignore memory outside of the linear range

[Ard Biesheuvel]

On 25 August 2015 at 12:02, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Aug 25, 2015 at 10:45:01AM +0100, Ard Biesheuvel wrote:
>> On 25 August 2015 at 00:34, Stuart Yoder <stuart.yoder@freescale.com> wrote:
>> >> On Mon, Aug 24, 2015 at 02:58:26PM +0100, Stuart Yoder wrote:
>> >> > Are we sending to stable as well?
>> >>
>> >> I've already pushed the patch out without a Cc stable (it's not a
>> >> regression afaict), so if you want it backported then you'll need to send
>> >> it to stable separately.
>> >
>> > Ok, was asking because of Catalin's previous comment:
>> >
>> >  > Even though it is not a regression, I think it is a bug fix and it's
>> >  > worth cc'ing stable (though we could push it after 4.3-rc1).
>> >
>>
>> Indeed. Catalin also mentioned that you and he discussed a minimal fix
>> with a cc to stable, only the fix itself was flawed. So let's not make
>> this Stuart's problem, considering that this issue breaks all arm64
>> systems with 32+ GB of RAM if they follow ARM's own recommendation
>> regarding the physical layout of memory.
>>
>> > Ard, are you going to send to stable?
>> >
>>
>> We'll have to wait until the merge window closes, of course, but yes,
>> we should propose it.
>>
>> @Will: what do you think? It would be nice to have you on record with
>> an opinion rather than leaving it up to Stuart.
>
> This isn't something that has *ever* worked with the arm64 kernel,
> right? In which case, it's not a regression, it's more like adding
> support for some systems that we've not supported before.

I am somewhat on the fence on this one, to be honest. The bug has
always existed but since DRAM is upgradeable, it may affect systems
that we do support and are working fine currently.

> Now, given the
> nature of the patch, I'm not against stable, but by the time Stuart
> pointed that out, I'd already pushed the patch and I don't want to
> rebase our 4.3 queue at this stage.
>

Noted. I just wanted to understand whether you had left it out on purpose.

> The best bet is to send this to stable once it's in mainline (i.e. -rc1)
> and I think it makes sense for Stuart to do that, since he is the one
> most interested in having that happen.
>

Indeed. I take Russell's point about fixes being important, but in
this case, I think it can wait until after the merge window.

-- 
Ard.