This is a followup to patch [1] (part of [2]) where I fixed an issue that I
identified related to commit dd006da21646 ("arm64: mm: increase VA range of
identity map").
Patch #1 fixes the issue in a way that should be compatible with v4.5 and
-stable, although it may conflict trivially on hunk context.
Patch #2 is a followup that changes memstart_addr to a signed type, which is
necessary when combining patch #1 with the linear region randomization patch
that is currently queued in -next.
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/481330
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/481327
Ard Biesheuvel (2):
arm64: vmemmap: use virtual projection of linear region
arm64: mm: treat memstart_addr as a signed quantity
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/include/asm/pgtable.h | 7 ++++---
arch/arm64/mm/init.c | 6 +++---
3 files changed, 8 insertions(+), 7 deletions(-)
--
2.5.0
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
---
v2: simplify the expression for vmemmap, forward compatible with the patch that
changes the type of memstart_addr to s64
arch/arm64/include/asm/pgtable.h | 7 ++++---
arch/arm64/mm/init.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
From: David Daney <hidden> Date: 2016-03-08 01:07:41
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
---
v2: simplify the expression for vmemmap, forward compatible with the patch that
changes the type of memstart_addr to s64
arch/arm64/include/asm/pgtable.h | 7 ++++---
arch/arm64/mm/init.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
On 8 mrt. 2016, at 08:07, David Daney [off-list ref] wrote:
quoted
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
I see this commit now in Linus' kernel.org tree in v4.5-rc7.
FYI: I am seeing a crash that goes away when I revert this. My kernel has some other modifications (our NUMA patches) so I haven't yet fully tracked this down on an unmodified kernel, but this is what I am getting:
Hi David,
You are the second one to report this issue on a 64k pages kernel, but i haven't managed to reproduce yet.
Any chance you could instrument vmemmap_populate_basepages to figure out whether the faulting address is populated, and if not, why?
Thanks,
Ard.
---
v2: simplify the expression for vmemmap, forward compatible with the patch that
changes the type of memstart_addr to s64
arch/arm64/include/asm/pgtable.h | 7 ++++---
arch/arm64/mm/init.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
On 8 March 2016 at 09:15, Ard Biesheuvel [off-list ref] wrote:
quoted
On 8 mrt. 2016, at 08:07, David Daney [off-list ref] wrote:
quoted
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
I see this commit now in Linus' kernel.org tree in v4.5-rc7.
FYI: I am seeing a crash that goes away when I revert this. My kernel has some other modifications (our NUMA patches) so I haven't yet fully tracked this down on an unmodified kernel, but this is what I am getting:
I managed to reproduce and diagnose this. The problem is that vmemmap
is no longer zone aligned, which causes trouble in the zone based
rounding that occurs in memory_present. The below patch fixes this by
rounding down the subtracted offset. Since this implies that the
region could stick off the other end, it also reverts the halving of
the region size.
--------8<----------
From: Mark Langsdorf <hidden> Date: 2016-03-08 13:17:42
On 03/08/2016 04:31 AM, Ard Biesheuvel wrote:
On 8 March 2016 at 09:15, Ard Biesheuvel [off-list ref] wrote:
quoted
quoted
On 8 mrt. 2016, at 08:07, David Daney [off-list ref] wrote:
quoted
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
I see this commit now in Linus' kernel.org tree in v4.5-rc7.
FYI: I am seeing a crash that goes away when I revert this. My kernel has some other modifications (our NUMA patches) so I haven't yet fully tracked this down on an unmodified kernel, but this is what I am getting:
I managed to reproduce and diagnose this. The problem is that vmemmap
is no longer zone aligned, which causes trouble in the zone based
rounding that occurs in memory_present. The below patch fixes this by
rounding down the subtracted offset. Since this implies that the
region could stick off the other end, it also reverts the halving of
the region size.
This fixes the bug on my Seattle B0 system.
Tested-by: Mark Langsdorf <redacted>
--Mark Langsdorf
On 8 March 2016 at 20:17, Mark Langsdorf [off-list ref] wrote:
On 03/08/2016 04:31 AM, Ard Biesheuvel wrote:
quoted
On 8 March 2016 at 09:15, Ard Biesheuvel [off-list ref]
wrote:
quoted
quoted
On 8 mrt. 2016, at 08:07, David Daney [off-list ref] wrote:
quoted
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map")
made
some changes to the memory mapping code to allow physical memory to
reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size
of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following
output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB
maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB
actual)
We can fix this by deciding that the vmemmap region is not a projection
of
the physical space, but of the virtual space above PAGE_OFFSET, i.e.,
the
linear region. This way, we are guaranteed that the vmemmap region is
of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
I see this commit now in Linus' kernel.org tree in v4.5-rc7.
FYI: I am seeing a crash that goes away when I revert this. My kernel
has some other modifications (our NUMA patches) so I haven't yet fully
tracked this down on an unmodified kernel, but this is what I am getting:
I managed to reproduce and diagnose this. The problem is that vmemmap
is no longer zone aligned, which causes trouble in the zone based
rounding that occurs in memory_present. The below patch fixes this by
rounding down the subtracted offset. Since this implies that the
region could stick off the other end, it also reverts the halving of
the region size.
This fixes the bug on my Seattle B0 system.
Tested-by: Mark Langsdorf <redacted>
On 8 March 2016 at 09:15, Ard Biesheuvel [off-list ref] wrote:
quoted
quoted
On 8 mrt. 2016, at 08:07, David Daney [off-list ref] wrote:
quoted
On 02/26/2016 08:57 AM, Ard Biesheuvel wrote:
Commit dd006da21646 ("arm64: mm: increase VA range of identity map") made
some changes to the memory mapping code to allow physical memory to reside
at an offset that exceeds the size of the virtual mapping.
However, since the size of the vmemmap area is proportional to the size of
the VA area, but it is populated relative to the physical space, we may
end up with the struct page array being mapped outside of the vmemmap
region. For instance, on my Seattle A0 box, I can see the following output
in the dmesg log.
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbfc0000000 - 0xffffffbfd0000000 ( 256 MB actual)
We can fix this by deciding that the vmemmap region is not a projection of
the physical space, but of the virtual space above PAGE_OFFSET, i.e., the
linear region. This way, we are guaranteed that the vmemmap region is of
sufficient size, and we can even reduce the size by half.
Signed-off-by: Ard Biesheuvel <redacted>
I see this commit now in Linus' kernel.org tree in v4.5-rc7.
FYI: I am seeing a crash that goes away when I revert this. My kernel has some other modifications (our NUMA patches) so I haven't yet fully tracked this down on an unmodified kernel, but this is what I am getting:
I managed to reproduce and diagnose this. The problem is that vmemmap
is no longer zone aligned, which causes trouble in the zone based
rounding that occurs in memory_present. The below patch fixes this by
rounding down the subtracted offset. Since this implies that the
region could stick off the other end, it also reverts the halving of
the region size.
I have seen the same panic. The fix solves the problem. See enclosed
diff for reference as there was some patch corruption of the original.
Thanks,
-Robert
From 562760cc30905748cb851cc9aee2bb9d88c67d47 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <redacted>
Date: Tue, 8 Mar 2016 17:31:05 +0700
Subject: [PATCH] arm64: vmemmap: Fix use virtual projection of linear region
Signed-off-by: Robert Richter <redacted>
---
arch/arm64/include/asm/pgtable.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Robert Richter <hidden> Date: 2016-03-09 11:36:38
On 09.03.16 12:32:14, Robert Richter wrote:
On 08.03.16 17:31:05, Ard Biesheuvel wrote:
quoted
On 8 March 2016 at 09:15, Ard Biesheuvel [off-list ref] wrote:
quoted
I managed to reproduce and diagnose this. The problem is that vmemmap
is no longer zone aligned, which causes trouble in the zone based
rounding that occurs in memory_present. The below patch fixes this by
rounding down the subtracted offset. Since this implies that the
region could stick off the other end, it also reverts the halving of
the region size.
I have seen the same panic. The fix solves the problem. See enclosed
diff for reference as there was some patch corruption of the original.
So this is:
Tested-by: Robert Richter <redacted>
-Robert
Commit c031a4213c11 ("arm64: kaslr: randomize the linear region")
implements randomization of the linear region, by subtracting a random
multiple of PUD_SIZE from memstart_addr. This causes the virtual mapping
of system RAM to move upwards in the linear region, and at the same time
causes memstart_addr to assume a value which may be negative if the offset
of system RAM in the physical space is smaller than its offset relative to
PAGE_OFFSET in the virtual space.
Since memstart_addr is effectively an offset now, redefine its type as s64
so that expressions involving shifting or division preserve its sign.
Signed-off-by: Ard Biesheuvel <redacted>
---
arch/arm64/include/asm/memory.h | 2 +-
arch/arm64/mm/init.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On 26 February 2016 at 17:57, Ard Biesheuvel [off-list ref] wrote:
Commit c031a4213c11 ("arm64: kaslr: randomize the linear region")
implements randomization of the linear region, by subtracting a random
multiple of PUD_SIZE from memstart_addr. This causes the virtual mapping
of system RAM to move upwards in the linear region, and at the same time
causes memstart_addr to assume a value which may be negative if the offset
of system RAM in the physical space is smaller than its offset relative to
PAGE_OFFSET in the virtual space.
Since memstart_addr is effectively an offset now, redefine its type as s64
so that expressions involving shifting or division preserve its sign.
Signed-off-by: Ard Biesheuvel <redacted>
On Fri, Feb 26, 2016 at 05:57:14PM +0100, Ard Biesheuvel wrote:
Commit c031a4213c11 ("arm64: kaslr: randomize the linear region")
implements randomization of the linear region, by subtracting a random
multiple of PUD_SIZE from memstart_addr. This causes the virtual mapping
of system RAM to move upwards in the linear region, and at the same time
causes memstart_addr to assume a value which may be negative if the offset
of system RAM in the physical space is smaller than its offset relative to
PAGE_OFFSET in the virtual space.
Since memstart_addr is effectively an offset now, redefine its type as s64
so that expressions involving shifting or division preserve its sign.
Signed-off-by: Ard Biesheuvel <redacted>