arm64: ignore memory outside of the linear range
Subsystems (2)
cover 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(-)
Signature · 1 line
1.9.1
PATCH 1/2 of/fdt: make memblock maximum physical address arch configurable
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.
--- drivers/of/fdt.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/of/fdt.c +7 -5
@@ -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) {
Signature · 1 line
1.9.1
Catalin Marinas
maintainerPATCH 1/2 of/fdt: make memblock maximum physical address arch configurable
Quoted 9 lines · 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_tis 64 bits (i.e., no limit) but there may be other constraints that limit the memory ranges that we can support.
Quoted 4 lines
So rename
MAX_PHYS_ADDRtoMAX_MEMBLOCK_ADDR(for clarity) and only define it if the arch does not supply a definition of its own.Signed-off-by Ard Biesheuvel <[email protected]>
Rob Herring
maintainerPATCH 1/2 of/fdt: make memblock maximum physical address arch configurable
In reply to Ard BiesheuvelQuoted 9 lines · 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_tis 64 bits (i.e., no limit) but there may be other constraints that limit the memory ranges that we can support.
Quoted 4 lines
So rename
MAX_PHYS_ADDRtoMAX_MEMBLOCK_ADDR(for clarity) and only define it if the arch does not supply a definition of its own.Signed-off-by Ard Biesheuvel <[email protected]>
Quoted 43 lines
--- drivers/of/fdt.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)drivers/of/fdt.c +7
-6@@ -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
In reply to Ard BiesheuvelThe 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.
--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/arm64/include/asm/memory.h +8 -0
@@ -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. *
Signature · 1 line
1.9.1
PATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 19 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 9 lines
arch/arm64/include/asm/memory.h +6
-0@@ -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
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })
Quoted 13 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor 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.
Signature · 1 line
Ard.
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 36 lines · Ard Biesheuvel
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor similar reasons.
Quoted 5 lines
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.
Signature · 1 line
Catalin
PATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 43 lines · Catalin Marinas
Quoted 36 lines · Ard Biesheuvel
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor similar reasons.Quoted 5 lines
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.
Quoted 5 lines
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 ?
Quoted 8 lines
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 thanULONG_MAXis pointless on 64-bit.Thanks.
--
Catalin
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 44 lines · Ard Biesheuvel
Quoted 43 lines · Catalin Marinas
Quoted 41 lines · Ard Biesheuvel
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor 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.
Quoted 6 lines
Quoted 4 lines
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.
Signature · 1 line
Catalin
PATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
In reply to Catalin MarinasQuoted 43 lines · Catalin Marinas
Quoted 36 lines · Ard Biesheuvel
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor similar reasons.Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 8 lines
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 thanULONG_MAXis pointless on 64-bit.Thanks.
--
Catalin
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 44 lines · Ard Biesheuvel
Quoted 43 lines · Catalin Marinas
Quoted 41 lines · Ard Biesheuvel
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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_limitto this value and changedearly_memto use min (i.e. only restrict the limit further), would that avoid the need to change the of code? It looks like PPC usesmemblock_enforce_memory_limitfor 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.
Quoted 7 lines
Quoted 4 lines
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).
Signature · 1 line
Catalin
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
In reply to Will DeaconQuoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })
Quoted 7 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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:
drivers/of/fdt.c +1 -1
@@ -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) {
Quoted 3 lines
If we initialised
memory_limitto this value and changedearly_memto 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.
Signature · 1 line
Catalin
PATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 23 lines · Catalin Marinas
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })
Quoted 12 lines
Quoted 7 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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.
Quoted 31 lines
drivers/of/fdt.c +1
-1@@ -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) {Quoted 4 lines
If we initialised
memory_limitto this value and changedearly_memto 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_limitstatically sincememstart_addris not constant. We would need to do this somewhere beforeearly_mem()is run (insetup_machine_fdtor 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 belowPHYS_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
Quoted 37 lines · Ard Biesheuvel
Quoted 23 lines · Catalin Marinas
Quoted 22 lines · Will Deacon
Quoted 21 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 12 lines
Quoted 7 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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:
Quoted 2 lines
Every 32-bit DT arch with highmem, quite likely.
I mean (L)PAE, of course
Quoted 32 lines
Quoted 32 lines
drivers/of/fdt.c +1
-1@@ -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) {Quoted 4 lines
If we initialised
memory_limitto this value and changedearly_memto 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_limitstatically sincememstart_addris not constant. We would need to do this somewhere beforeearly_mem()is run (insetup_machine_fdtor 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 belowPHYS_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
In reply to Catalin MarinasQuoted 3 lines · Catalin Marinas
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.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 8 lines · Russell King - ARM Linux
Quoted 3 lines · Catalin Marinas
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.
Signature · 1 line
Catalin
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
In reply to Ard BiesheuvelQuoted 19 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/include/asm/memory.h | 8 ++++++++ 1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 9 lines
arch/arm64/include/asm/memory.h +6
-0@@ -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:
PATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 26 lines · Catalin Marinas
Quoted 23 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>---
arch/arm64/include/asm/memory.h| 8 ++++++++1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })
Quoted 10 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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
Quoted 3 lines
Otherwise:
Reviewed-by Catalin Marinas <[email protected]>
Thanks
Catalin Marinas
maintainerPATCH 2/2 arm64: set MAX_MEMBLOCK_ADDR according to linear region size
Quoted 36 lines · Ard Biesheuvel
Quoted 26 lines · Catalin Marinas
Quoted 23 lines · 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_ADDRaccordingly.Signed-off-by Ard Biesheuvel <[email protected]>---
arch/arm64/include/asm/memory.h| 8 ++++++++1 file changed, 8 insertions(+)arch/arm64/include/asm/memory.h +0
-0@@ -114,6 +114,14 @@ extern phys_addr_t memstart_addr;#define PHYS_OFFSET ({ memstart_addr; })Quoted 9 lines
arch/arm64/include/asm/memory.h extern phys_addr_t memstart_addr; · line 122
Quoted 7 lines
arch/arm64/include/asm/memory.h +6
-0/* +* 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?
Quoted 1 line
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.
Signature · 1 line
Catalin
cover arm64: ignore memory outside of the linear range
In reply to Ard BiesheuvelQuoted 21 lines
-----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 rangeThis 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.
Quoted 7 lines
Ard Biesheuvel (2):
of/fdt: make memblock maximum physical address arch configurable
arm64: setMAX_MEMBLOCK_ADDRaccording to linear region sizearch/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.
Thanks,
Stuart
cover arm64: ignore memory outside of the linear range
Quoted 25 lines · Stuart Yoder
Quoted 25 lines
-----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 rangeThis 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: setMAX_MEMBLOCK_ADDRaccording to linear region size
Quoted 9 lines
Quoted 3 lines
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 <[email protected]>
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.
cover arm64: ignore memory outside of the linear range
Quoted 20 lines · Ard Biesheuvel
Quoted 20 lines
Quoted 19 lines
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: setMAX_MEMBLOCK_ADDRaccording to linear region sizearch/arm64/include/asm/memory.h | 8 ++++++++ drivers/of/fdt.c | 12 +++++++----- 2 files changed, 15 insertions(+), 5 deletions(-)
Quoted 8 lines
Quoted 5 lines
Tested on Freescale LS2085ARDB which has a split memory region that triggers the bug.
Tested-by Stuart Yoder <[email protected]>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
cover arm64: ignore memory outside of the linear range
Quoted 33 lines
-----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 rangeQuoted 23 lines · Ard Biesheuvel
Quoted 23 lines
Quoted 12 lines
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.
Quoted 7 lines
Ard Biesheuvel (2):
of/fdt: make memblock maximum physical address arch configurable
arm64: setMAX_MEMBLOCK_ADDRaccording to linear region sizearch/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.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Tested-by Stuart Yoder <[email protected]>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.cchange. I'll pick these up later today, no need to resend.
Are we sending to stable as well?
Stuart
cover arm64: ignore memory outside of the linear range
Quoted 27 lines · Stuart Yoder
Quoted 27 lines · Ard Biesheuvel
Quoted 26 lines
Quoted 25 lines
Quoted 12 lines
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.
Quoted 7 lines
Ard Biesheuvel (2):
of/fdt: make memblock maximum physical address arch configurable
arm64: setMAX_MEMBLOCK_ADDRaccording to linear region sizearch/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 <[email protected]>
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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.cchange. 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
cover arm64: ignore memory outside of the linear range
Quoted 40 lines
-----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 rangeQuoted 30 lines · Stuart Yoder
Quoted 30 lines · Ard Biesheuvel
Quoted 28 lines
Quoted 16 lines
Quoted 16 lines
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: setMAX_MEMBLOCK_ADDRaccording to linear region sizeQuoted 9 lines
Quoted 3 lines
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 <[email protected]>Will you be picking up this series for v4.3? If so, do you need me to resend it with the tags added?
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
Sorry, I missed Rob's ack on the
of/fdt.cchange. 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:
Quoted 2 lines
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
cover arm64: ignore memory outside of the linear range
Quoted 43 lines · Stuart Yoder
Quoted 43 lines
-----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 rangeQuoted 33 lines · Stuart Yoder
Quoted 32 lines · Ard Biesheuvel
Quoted 20 lines
Quoted 20 lines
Quoted 19 lines
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: setMAX_MEMBLOCK_ADDRaccording to linear region sizearch/arm64/include/asm/memory.h | 8 ++++++++ drivers/of/fdt.c | 12 +++++++----- 2 files changed, 15 insertions(+), 5 deletions(-)Quoted 8 lines
Quoted 5 lines
Tested on Freescale LS2085ARDB which has a split memory region that triggers the bug.
Tested-by Stuart Yoder <[email protected]>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.cchange. I'll pick these up later today, no need to resend.
Quoted 11 lines
Quoted 5 lines
Quoted 1 line
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:
Quoted 2 lines
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.
Quoted 2 lines
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.
Signature · 1 line
Ard.
cover arm64: ignore memory outside of the linear range
Quoted 6 lines · Ard Biesheuvel
Quoted 2 lines · Stuart Yoder
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.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
cover arm64: ignore memory outside of the linear range
In reply to Ard BiesheuvelQuoted 20 lines · Ard Biesheuvel
Quoted 12 lines · Stuart Yoder
Quoted 6 lines · Stuart Yoder
Quoted 1 line
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:
Quoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
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
cover arm64: ignore memory outside of the linear range
Quoted 27 lines · Will Deacon
Quoted 26 lines · Ard Biesheuvel
Quoted 12 lines · Stuart Yoder
Quoted 6 lines · Stuart Yoder
Quoted 1 line
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:
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
@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.
Quoted 5 lines
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.
Quoted 4 lines
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.
Signature · 1 line
Ard.