[PATCH 1/2] x86_64: fix mm.txt documentation

[PATCH 1/2] x86_64: fix mm.txt documentation

[Jiri Slaby]

Commit 85eb69a16aab5a394ce043c2131319eae35e6493 introduced 512 MiB
sized kernel and 1.5 GiB sized module space but omitted to change
documentation properly. Fix that.

[Wasn't the hole intentional protection hole?]

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
---
 Documentation/x86_64/mm.txt |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/x86_64/mm.txt b/Documentation/x86_64/mm.txt
index b89b6d2..efce750 100644
--- a/Documentation/x86_64/mm.txt
+++ b/Documentation/x86_64/mm.txt
@@ -11,9 +11,8 @@ ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole
 ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space
 ffffe20000000000 - ffffe2ffffffffff (=40 bits) virtual memory map (1TB)
 ... unused hole ...
-ffffffff80000000 - ffffffff82800000 (=40 MB)   kernel text mapping, from phys 0
-... unused hole ...
-ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space
+ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
+ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
 
 The direct mapping covers all memory in the system up to the highest
 memory address (this means in some cases it can also include PCI memory
-- 
1.5.4.5

[PATCH 2/2] x86_64: use PAGE_OFFSET in dump_pagetables

[Jiri Slaby]

Use PAGE_OFFSET macro instead of using 0xffff810000000000UL directly.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: tglx@linutronix.de
Cc: mingo@redhat.com
Cc: hpa@zytor.com
---
 arch/x86/mm/dump_pagetables.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 6791b83..6f8e3fe 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -42,7 +42,7 @@ static struct addr_marker address_markers[] = {
 	{ 0, "User Space" },
 #ifdef CONFIG_X86_64
 	{ 0x8000000000000000UL, "Kernel Space" },
-	{ 0xffff810000000000UL, "Low Kernel Mapping" },
+	{ PAGE_OFFSET,		"Low Kernel Mapping" },
 	{ VMALLOC_START,        "vmalloc() Area" },
 	{ VMEMMAP_START,        "Vmemmap" },
 	{ __START_KERNEL_map,   "High Kernel Mapping" },
-- 
1.5.4.5

Re: [PATCH 2/2] x86_64: use PAGE_OFFSET in dump_pagetables

[Ingo Molnar]

* Jiri Slaby <jirislaby@gmail.com> wrote:

> Use PAGE_OFFSET macro instead of using 0xffff810000000000UL directly.

thanks Jiri, applied.

	Ingo

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Ingo Molnar]

* Jiri Slaby <jirislaby@gmail.com> wrote:

> Commit 85eb69a16aab5a394ce043c2131319eae35e6493 introduced 512 MiB 
> sized kernel and 1.5 GiB sized module space but omitted to change 
> documentation properly. Fix that.

thanks Jiri, applied.

> [Wasn't the hole intentional protection hole?]

> -ffffffff80000000 - ffffffff82800000 (=40 MB)   kernel text mapping, from phys 0
> -... unused hole ...
> -ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space
> +ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
> +ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space

yep, the image was in a 128 MB chunk from which 88 MB was left empty and 
modules started at the next 128 MB boundary. The largest image i ever 
had was around 44MB, so i doubt it's an issue in practice. Mind doing a 
patch that reinstates it, by lowering the 512 image size limit to 508 
MB? [4MB should be more than enough in practice]

	Ingo

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Jiri Slaby]

On 05/02/2008 09:22 AM, Ingo Molnar wrote:
> Mind doing a 
> patch that reinstates it, by lowering the 512 image size limit to 508 
> MB?

Yup, I will.

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Andi Kleen]

> yep, the image was in a 128 MB chunk from which 88 MB was left empty and 
> modules started at the next 128 MB boundary. The largest image i ever 
> had was around 44MB, so i doubt it's an issue in practice. Mind doing a 
> patch that reinstates it, by lowering the 512 image size limit to 508 
> MB? [4MB should be more than enough in practice]

Actually you could even limit to the exact know size of the kernel (rounded
up to 2MB) after early boot. Then the protection would be even better and less
aliasing to deal with for pageattr.c. Just invalidate the left over PMDs.

-Andi

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Jiri Slaby]

On 05/02/2008 10:38 AM, Andi Kleen wrote:
>> yep, the image was in a 128 MB chunk from which 88 MB was left empty and 
>> modules started at the next 128 MB boundary. The largest image i ever 
>> had was around 44MB, so i doubt it's an issue in practice. Mind doing a 
>> patch that reinstates it, by lowering the 512 image size limit to 508 
>> MB? [4MB should be more than enough in practice]
> 
> Actually you could even limit to the exact know size of the kernel (rounded
> up to 2MB) after early boot. Then the protection would be even better and less
> aliasing to deal with for pageattr.c. Just invalidate the left over PMDs.

Doesn't cleanup_highmap() do that? ... so I guess we don't need the hole? Or do 
we when we reach the limit to not go over to modules?

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Andi Kleen]

On Thu, May 01, 2008 at 11:58:18AM +0200, Jiri Slaby wrote:
> Commit 85eb69a16aab5a394ce043c2131319eae35e6493 introduced 512 MiB
> sized kernel and 1.5 GiB sized module space but omitted to change
> documentation properly. Fix that.
> 
> [Wasn't the hole intentional protection hole?]

Yes it was.

-Andi

Re: [PATCH 1/2] x86_64: fix mm.txt documentation

[Jiri Slaby]

On 05/02/2008 10:00 AM, Andi Kleen wrote:
> On Thu, May 01, 2008 at 11:58:18AM +0200, Jiri Slaby wrote:
>> Commit 85eb69a16aab5a394ce043c2131319eae35e6493 introduced 512 MiB
>> sized kernel and 1.5 GiB sized module space but omitted to change
>> documentation properly. Fix that.
>>
>> [Wasn't the hole intentional protection hole?]
> 
> Yes it was.

Thanks. Going to post a patch to re-introduce the hole.