arm64: ignore memory outside of the linear range
PATCH 1/1 arm64: ignore memory outside of the linear range
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
---
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
arch/arm64/mm/init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
arch/arm64/mm/init.c +13 -0
@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. +*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +memblock_enforce_memory_limit (memory_limit);/*
Signature · 1 line
1.9.1
PATCH 1/1 arm64: ignore memory outside of the linear range
Hi Ard,
Quoted 31 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
arch/arm64/mm/init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm64/mm/init.c +3
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping.
arch/arm64/mm/init.c early_param("mem", early_mem); · line 173
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +
I think this will interact badly with Mark Salter's patches to relocate the initrd if it falls outside of the linear mapping (which relies on the memblocks remaining intact after paging_init):
https://lkml.org/lkml/2015/8/16/75
Some version of those patches got queued via akpm (since there is a dependency on some generic + x86 changes), so we'd need to work out how these two changes interact before merging this,
Will
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 49 lines · Will Deacon
Hi Ard,
Quoted 31 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
arch/arm64/mm/init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm64/mm/init.c +3
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. arch/arm64/mm/init.c early_param("mem", early_mem); · line 173
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +I think this will interact badly with Mark Salter's patches to relocate the initrd if it falls outside of the linear mapping (which relies on the memblocks remaining intact after
paging_init):
Quoted 2 lines
Are you sure? By the looks of it, these patches combined would correctly address the case where no mem= is passed, but the initial ramdisk is loaded past the end of the linear region.
I.e., memblock_end_of_DRAM() will return the clipped value, which would be smaller than orig_end, triggering the relocation machinery which moves it inside the linear region.
Signature · 1 line
Ard.
Quoted 4 lines
Some version of those patches got queued via akpm (since there is a dependency on some generic + x86 changes), so we'd need to work out how these two changes interact before merging this,
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 53 lines · Ard Biesheuvel
Quoted 49 lines · Will Deacon
Hi Ard,
Quoted 31 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
arch/arm64/mm/init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm64/mm/init.c +3
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. arch/arm64/mm/init.c early_param("mem", early_mem); · line 173
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +I think this will interact badly with Mark Salter's patches to relocate the initrd if it falls outside of the linear mapping (which relies on the memblocks remaining intact after
paging_init):Quoted 2 lines
Quoted 7 lines
Are you sure? By the looks of it, these patches combined would correctly address the case where no mem= is passed, but the initial ramdisk is loaded past the end of the linear region.
I.e.,
memblock_end_of_DRAM()will return the clipped value, which would be smaller thanorig_end, triggering the relocation machinery which moves it inside the linear region.
Ok. I was trying to consider the case where the initrd is outside of the linear mapping not because of a restrictive "mem=", but because its out of range of our page tables. AFAICT, we'll end up attempting to memcpy the thing back down (but I appreciate that things won't work without your patch too).
Will
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 62 lines · Will Deacon
Quoted 53 lines · Ard Biesheuvel
Quoted 49 lines · Will Deacon
Hi Ard,
Quoted 31 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
arch/arm64/mm/init.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)arch/arm64/mm/init.c +3
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. arch/arm64/mm/init.c early_param("mem", early_mem); · line 173
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +I think this will interact badly with Mark Salter's patches to relocate the initrd if it falls outside of the linear mapping (which relies on the memblocks remaining intact after
paging_init):Quoted 2 lines
Quoted 7 lines
Are you sure? By the looks of it, these patches combined would correctly address the case where no mem= is passed, but the initial ramdisk is loaded past the end of the linear region.
I.e.,
memblock_end_of_DRAM()will return the clipped value, which would be smaller thanorig_end, triggering the relocation machinery which moves it inside the linear region.
Quoted 6 lines
Ok. I was trying to consider the case where the initrd is outside of the linear mapping not because of a restrictive "mem=", but because its out of range of our page tables. AFAICT, we'll end up attempting to memcpy the thing back down (but I appreciate that things won't work without your patch too).
But isn't the whole point of Mark's patches that the source initrd is memremap()'d and copied to a destination that is covered by the kernel direct mapping? I.e., mem= is enforced in the exact same place where this code is added, and so the initrd will not be mapped if it is outside of mem=
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 48 lines · Ard Biesheuvel
Quoted 40 lines · Will Deacon
Quoted 31 lines · Ard Biesheuvel
Quoted 27 lines · Will Deacon
Quoted 11 lines · Ard Biesheuvel
arch/arm64/mm/init.c +3
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. arch/arm64/mm/init.c early_param("mem", early_mem); · line 173
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + } +I think this will interact badly with Mark Salter's patches to relocate the initrd if it falls outside of the linear mapping (which relies on the memblocks remaining intact after
paging_init):Quoted 2 lines
Quoted 7 lines
Are you sure? By the looks of it, these patches combined would correctly address the case where no mem= is passed, but the initial ramdisk is loaded past the end of the linear region.
I.e.,
memblock_end_of_DRAM()will return the clipped value, which would be smaller thanorig_end, triggering the relocation machinery which moves it inside the linear region.Quoted 6 lines
Ok. I was trying to consider the case where the initrd is outside of the linear mapping not because of a restrictive "mem=", but because its out of range of our page tables. AFAICT, we'll end up attempting to memcpy the thing back down (but I appreciate that things won't work without your patch too).
Quoted 5 lines
But isn't the whole point of Mark's patches that the source initrd is memremap()'d and copied to a destination that is covered by the kernel direct mapping? I.e., mem= is enforced in the exact same place where this code is added, and so the initrd will not be mapped if it is outside of mem=
Yes, you're right. I'd somehow confused myself with the to_free case, but it all falls out in the wash and we'll map what we need to map before copying the initrd down.
Will
Catalin Marinas
maintainerPATCH 1/1 arm64: ignore memory outside of the linear range
In reply to Ard BiesheuvelQuoted 8 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 8 lines
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
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).
Quoted 10 lines
arch/arm64/mm/init.c +2
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover
arch/arm64/mm/init.c early_param("mem", early_mem); · line 172
Quoted 10 lines
arch/arm64/mm/init.c +10
-0+* with the linear mapping. +*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX ); + }
For memory blocks below PHYS_OFFSET, we ignore them in early_init_dt_add_memory_arch() directly (and also print a warning). Could we not do something similar for higher blocks? This function has a check for MAX_PHYS_ADDR but thats -1ULL, so I guess the check is pretty much useless. We should allow the arch code define this macro and only leave the current value as default if not overridden.
Signature · 1 line
Catalin
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 40 lines · Catalin Marinas
Quoted 8 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 8 lines
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
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).
Quoted 19 lines
arch/arm64/mm/init.c +11
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. +*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX );
Quoted 9 lines
arch/arm64/mm/init.c early_param("mem", early_mem); · line 172
Quoted 1 line
arch/arm64/mm/init.c +1
-0+ }For memory blocks below
PHYS_OFFSET, we ignore them inearly_init_dt_add_memory_arch()directly (and also print a warning). Could we not do something similar for higher blocks? This function has a check forMAX_PHYS_ADDRbut thats -1ULL, so I guess the check is pretty much useless. We should allow the arch code define this macro and only leave the current value as default if not overridden.
That is actually more or less what Mark Rutland proposed here
http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
although his definition of the upper bound is incorrect.
I proposed to override early_init_dt_add_memory_arch() completely instead, but Rob had some comments, after which the discussion kind of fizzled out.
Since Stuart brought the issue back up, I responded with this version that does the bare minimum.
Catalin Marinas
maintainerPATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 51 lines · Ard Biesheuvel
Quoted 40 lines · Catalin Marinas
Quoted 8 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 8 lines
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
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).
Quoted 19 lines
arch/arm64/mm/init.c +11
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. +*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX );Quoted 9 lines
arch/arm64/mm/init.c early_param("mem", early_mem); · line 172
Quoted 1 line
arch/arm64/mm/init.c +1
-0+ }For memory blocks below
PHYS_OFFSET, we ignore them inearly_init_dt_add_memory_arch()directly (and also print a warning). Could we not do something similar for higher blocks? This function has a check forMAX_PHYS_ADDRbut thats -1ULL, so I guess the check is pretty much useless. We should allow the arch code define this macro and only leave the current value as default if not overridden.
Quoted 3 lines
That is actually more or less what Mark Rutland proposed here
http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
Ah, I missed this. I prefer Mark's variant more (once it's fixed).
Quoted 3 lines
I proposed to override
early_init_dt_add_memory_arch()completely instead, but Rob had some comments, after which the discussion kind of fizzled out.
I don't think we should override early_init_dt_add_memory_arch(), unless we diverge too much from it. Currently, it looks to me like the end of PA range check is pretty useless in this function.
Signature · 1 line
Catalin
PATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 58 lines · Catalin Marinas
Quoted 51 lines · Ard Biesheuvel
Quoted 40 lines · Catalin Marinas
Quoted 8 lines · Ard Biesheuvel
We need to ensure that we don't try to map system RAM ranges whose offset relative to the start of the kernel image exceeds the size of the linear range. This may happen even on systems that don't have huge amounts of RAM if it is laid out very sparsely.
Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 8 lines
This is the minimal fix for addressing the issue we discussed. I dropped the other changes for now, let's revisit those when (if) my patches for decoupling the kernel mapping from the linear mapping are back under discussion.
I will leave it up to the maintainers whether this constitutes a bugfix or not, but since this has never worked from the beginning afaict, I don't think it belongs in stable per se.
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).
Quoted 19 lines
arch/arm64/mm/init.c +11
-0@@ -158,6 +158,19 @@ early_param("mem", early_mem);void __init arm64_memblock_init (void ) { +/* +* Remove the memory that we will not be able to cover +* with the linear mapping. +*/ +const s64 linear_region_size = -(s64 )PAGE_OFFSET ; + +if (memstart_addr + linear_region_size <memblock_end_of_DRAM ()) { +pr_warn ("Ignoring memory outside of linear range (0x%012llx - 0x%012llx)\n" , + memstart_addr + linear_region_size, + (u64 )memblock_end_of_DRAM () -1 ); +memblock_remove (memstart_addr + linear_region_size,ULLONG_MAX );Quoted 9 lines
arch/arm64/mm/init.c early_param("mem", early_mem); · line 172
Quoted 1 line
arch/arm64/mm/init.c +1
-0+ }For memory blocks below
PHYS_OFFSET, we ignore them inearly_init_dt_add_memory_arch()directly (and also print a warning). Could we not do something similar for higher blocks? This function has a check forMAX_PHYS_ADDRbut thats -1ULL, so I guess the check is pretty much useless. We should allow the arch code define this macro and only leave the current value as default if not overridden.Quoted 3 lines
That is actually more or less what Mark Rutland proposed here
http://article.gmane.org/gmane.linux.ports.arm.kernel/430239
Ah, I missed this. I prefer Mark's variant more (once it's fixed).
Quoted 8 lines
Quoted 3 lines
I proposed to override
early_init_dt_add_memory_arch()completely instead, but Rob had some comments, after which the discussion kind of fizzled out.I don't think we should override
early_init_dt_add_memory_arch(), unless we diverge too much from it. Currently, it looks to me like the end of PA range check is pretty useless in this function.
OK. But note that, when we decouple the linear mapping from the mapping of the kernel image, we will need to override this function anyway.
Catalin Marinas
maintainerPATCH 1/1 arm64: ignore memory outside of the linear range
Quoted 6 lines · Ard Biesheuvel
Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Ard Biesheuvel
I proposed to override
early_init_dt_add_memory_arch()completely instead, but Rob had some comments, after which the discussion kind of fizzled out.
Quoted 7 lines
Quoted 3 lines
I don't think we should override
early_init_dt_add_memory_arch(), unless we diverge too much from it. Currently, it looks to me like the end of PA range check is pretty useless in this function.OK. But note that, when we decouple the linear mapping from the mapping of the kernel image, we will need to override this function anyway.
That's fine. I assume we'll keep the DT memblock checking in the same place. The main issue I have with your patch is the split of lower blocks rejected by one function and higher blocks by another.
Signature · 1 line
Catalin