All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Garnier <thgarnie@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Juergen Gross <jgross@suse.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Andy Lutomirski <luto@amacapital.net>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Jiri Kosina <jikos@kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Boris Ostrovsky <boris.o>
Subject: Re: [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size
Date: Thu, 16 Mar 2017 08:33:32 -0700	[thread overview]
Message-ID: <CAJcbSZEB09inR2KLF_puOnmAK7QUv-zJHcguiF0qucUYTtg1Pw@mail.gmail.com> (raw)
In-Reply-To: <20170316081013.GB7815@gmail.com>

On Thu, Mar 16, 2017 at 1:10 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Note that asm/fixmap.h is an x86-ism that isn't present in many other
> architectures, so this hunk will break the build.
>
> To make progress with these patches I've fixed it up with an ugly #ifdef
> CONFIG_X86, but it needs a real solution instead before this can be pushed
> upstream.

I also saw an error on x86 tip on special configuration. I found this
new patch below to be a good solution to both.

Let me know what you think.

=====

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
Based on next-20170308
---
 Documentation/x86/x86_64/mm.txt         | 5 ++++-
 arch/x86/include/asm/pgtable_64.h       | 1 +
 arch/x86/include/asm/pgtable_64_types.h | 3 ++-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5724092db811..ee3f9c30957c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -19,7 +19,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp
fixup stacks
 ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
 ... unused hole ...
 ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole

@@ -39,6 +39,9 @@ memory window (this size is arbitrary, it can be
raised later if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.

+The module mapping space size changes based on the CONFIG requirements for the
+following fixmap section.
+
 Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index 73c7ccc38912..67608d4abc2c 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -13,6 +13,7 @@
 #include <asm/processor.h>
 #include <linux/bitops.h>
 #include <linux/threads.h>
+#include <asm/fixmap.h>

 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..bb05e21cf3c7 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -67,7 +67,8 @@ typedef struct { pteval_t pte; } pte_t;
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
 #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END      _AC(0xffffffffff000000, UL)
+/* The module sections ends with the start of the fixmap */
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
-- 
2.12.0.367.g23dc2f6d3c-goog

-- 
Thomas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Garnier <thgarnie@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	Juergen Gross <jgross@suse.com>,
	Andy Lutomirski <luto@kernel.org>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Andy Lutomirski <luto@amacapital.net>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Jiri Kosina <jikos@kernel.org>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Boris Ostrovsky <boris.o
Subject: Re: [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size
Date: Thu, 16 Mar 2017 08:33:32 -0700	[thread overview]
Message-ID: <CAJcbSZEB09inR2KLF_puOnmAK7QUv-zJHcguiF0qucUYTtg1Pw@mail.gmail.com> (raw)
In-Reply-To: <20170316081013.GB7815@gmail.com>

On Thu, Mar 16, 2017 at 1:10 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Note that asm/fixmap.h is an x86-ism that isn't present in many other
> architectures, so this hunk will break the build.
>
> To make progress with these patches I've fixed it up with an ugly #ifdef
> CONFIG_X86, but it needs a real solution instead before this can be pushed
> upstream.

I also saw an error on x86 tip on special configuration. I found this
new patch below to be a good solution to both.

Let me know what you think.

=====

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
Based on next-20170308
---
 Documentation/x86/x86_64/mm.txt         | 5 ++++-
 arch/x86/include/asm/pgtable_64.h       | 1 +
 arch/x86/include/asm/pgtable_64_types.h | 3 ++-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5724092db811..ee3f9c30957c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -19,7 +19,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp
fixup stacks
 ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
 ... unused hole ...
 ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole

@@ -39,6 +39,9 @@ memory window (this size is arbitrary, it can be
raised later if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.

+The module mapping space size changes based on the CONFIG requirements for the
+following fixmap section.
+
 Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index 73c7ccc38912..67608d4abc2c 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -13,6 +13,7 @@
 #include <asm/processor.h>
 #include <linux/bitops.h>
 #include <linux/threads.h>
+#include <asm/fixmap.h>

 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..bb05e21cf3c7 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -67,7 +67,8 @@ typedef struct { pteval_t pte; } pte_t;
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
 #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END      _AC(0xffffffffff000000, UL)
+/* The module sections ends with the start of the fixmap */
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
-- 
2.12.0.367.g23dc2f6d3c-goog

-- 
Thomas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Garnier <thgarnie@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Lorenzo Stoakes" <lstoakes@gmail.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Juergen Gross" <jgross@suse.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Hocko" <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	"Stanislaw Gruszka" <sgruszka@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, kasan-dev <kasan-dev@googlegroups.com>,
	Linux-MM <linux-mm@kvack.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	linux-efi@vger.kernel.org, xen-devel@lists.xenproject.org,
	lguest@lists.ozlabs.org, "kvm list" <kvm@vger.kernel.org>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>
Subject: Re: [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size
Date: Thu, 16 Mar 2017 08:33:32 -0700	[thread overview]
Message-ID: <CAJcbSZEB09inR2KLF_puOnmAK7QUv-zJHcguiF0qucUYTtg1Pw@mail.gmail.com> (raw)
In-Reply-To: <20170316081013.GB7815@gmail.com>

On Thu, Mar 16, 2017 at 1:10 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Note that asm/fixmap.h is an x86-ism that isn't present in many other
> architectures, so this hunk will break the build.
>
> To make progress with these patches I've fixed it up with an ugly #ifdef
> CONFIG_X86, but it needs a real solution instead before this can be pushed
> upstream.

I also saw an error on x86 tip on special configuration. I found this
new patch below to be a good solution to both.

Let me know what you think.

=====

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
Based on next-20170308
---
 Documentation/x86/x86_64/mm.txt         | 5 ++++-
 arch/x86/include/asm/pgtable_64.h       | 1 +
 arch/x86/include/asm/pgtable_64_types.h | 3 ++-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5724092db811..ee3f9c30957c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -19,7 +19,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp
fixup stacks
 ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
 ... unused hole ...
 ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole

@@ -39,6 +39,9 @@ memory window (this size is arbitrary, it can be
raised later if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.

+The module mapping space size changes based on the CONFIG requirements for the
+following fixmap section.
+
 Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index 73c7ccc38912..67608d4abc2c 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -13,6 +13,7 @@
 #include <asm/processor.h>
 #include <linux/bitops.h>
 #include <linux/threads.h>
+#include <asm/fixmap.h>

 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..bb05e21cf3c7 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -67,7 +67,8 @@ typedef struct { pteval_t pte; } pte_t;
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
 #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END      _AC(0xffffffffff000000, UL)
+/* The module sections ends with the start of the fixmap */
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
-- 
2.12.0.367.g23dc2f6d3c-goog

-- 
Thomas

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Garnier <thgarnie@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Andrey Ryabinin" <aryabinin@virtuozzo.com>,
	"Alexander Potapenko" <glider@google.com>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Lorenzo Stoakes" <lstoakes@gmail.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Juergen Gross" <jgross@suse.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Michal Hocko" <mhocko@suse.com>, zijun_hu <zijun_hu@htc.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Matt Fleming" <matt@codeblueprint.co.uk>,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Rusty Russell" <rusty@rustcorp.com.au>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Christian Borntraeger" <borntraeger@de.ibm.com>,
	"Frederic Weisbecker" <fweisbec@gmail.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	"Stanislaw Gruszka" <sgruszka@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, kasan-dev <kasan-dev@googlegroups.com>,
	Linux-MM <linux-mm@kvack.org>,
	"Linux PM list" <linux-pm@vger.kernel.org>,
	linux-efi@vger.kernel.org, xen-devel@lists.xenproject.org,
	lguest@lists.ozlabs.org, "kvm list" <kvm@vger.kernel.org>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size
Date: Thu, 16 Mar 2017 08:33:32 -0700	[thread overview]
Message-ID: <CAJcbSZEB09inR2KLF_puOnmAK7QUv-zJHcguiF0qucUYTtg1Pw@mail.gmail.com> (raw)
In-Reply-To: <20170316081013.GB7815@gmail.com>

On Thu, Mar 16, 2017 at 1:10 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Note that asm/fixmap.h is an x86-ism that isn't present in many other
> architectures, so this hunk will break the build.
>
> To make progress with these patches I've fixed it up with an ugly #ifdef
> CONFIG_X86, but it needs a real solution instead before this can be pushed
> upstream.

I also saw an error on x86 tip on special configuration. I found this
new patch below to be a good solution to both.

Let me know what you think.

=====

This patch aligns MODULES_END to the beginning of the Fixmap section.
It optimizes the space available for both sections. The address is
pre-computed based on the number of pages required by the Fixmap
section.

It will allow GDT remapping in the Fixmap section. The current
MODULES_END static address does not provide enough space for the kernel
to support a large number of processors.

Signed-off-by: Thomas Garnier <thgarnie@google.com>
---
Based on next-20170308
---
 Documentation/x86/x86_64/mm.txt         | 5 ++++-
 arch/x86/include/asm/pgtable_64.h       | 1 +
 arch/x86/include/asm/pgtable_64_types.h | 3 ++-
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index 5724092db811..ee3f9c30957c 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -19,7 +19,7 @@ ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp
fixup stacks
 ffffffef00000000 - fffffffeffffffff (=64 GB) EFI region mapping space
 ... unused hole ...
 ffffffff80000000 - ffffffff9fffffff (=512 MB)  kernel text mapping, from phys 0
-ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space
+ffffffffa0000000 - ffffffffff5fffff (=1526 MB) module mapping space (variable)
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
 ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole

@@ -39,6 +39,9 @@ memory window (this size is arbitrary, it can be
raised later if needed).
 The mappings are not part of any other kernel PGD and are only available
 during EFI runtime calls.

+The module mapping space size changes based on the CONFIG requirements for the
+following fixmap section.
+
 Note that if CONFIG_RANDOMIZE_MEMORY is enabled, the direct mapping of all
 physical memory, vmalloc/ioremap space and virtual memory map are randomized.
 Their order is preserved but their base will be offset early at boot time.
diff --git a/arch/x86/include/asm/pgtable_64.h
b/arch/x86/include/asm/pgtable_64.h
index 73c7ccc38912..67608d4abc2c 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -13,6 +13,7 @@
 #include <asm/processor.h>
 #include <linux/bitops.h>
 #include <linux/threads.h>
+#include <asm/fixmap.h>

 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 3a264200c62f..bb05e21cf3c7 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -67,7 +67,8 @@ typedef struct { pteval_t pte; } pte_t;
 #endif /* CONFIG_RANDOMIZE_MEMORY */
 #define VMALLOC_END (VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
 #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
-#define MODULES_END      _AC(0xffffffffff000000, UL)
+/* The module sections ends with the start of the fixmap */
+#define MODULES_END   __fix_to_virt(__end_of_fixed_addresses + 1)
 #define MODULES_LEN   (MODULES_END - MODULES_VADDR)
 #define ESPFIX_PGD_ENTRY _AC(-2, UL)
 #define ESPFIX_BASE_ADDR (ESPFIX_PGD_ENTRY << PGDIR_SHIFT)
-- 
2.12.0.367.g23dc2f6d3c-goog

-- 
Thomas

  reply	other threads:[~2017-03-16 15:33 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14 17:05 [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size Thomas Garnier
2017-03-14 17:05 ` [kernel-hardening] " Thomas Garnier
2017-03-14 17:05 ` Thomas Garnier
2017-03-14 17:05 ` Thomas Garnier
2017-03-14 17:05 ` Thomas Garnier
2017-03-14 17:05 ` [PATCH v7 2/3] x86: Remap GDT tables in the Fixmap section Thomas Garnier
2017-03-14 17:05   ` [kernel-hardening] " Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-16 11:10   ` [tip:x86/mm] x86: Remap GDT tables in the fixmap section tip-bot for Thomas Garnier
2017-03-14 17:05 ` [PATCH v7 2/3] x86: Remap GDT tables in the Fixmap section Thomas Garnier
2017-03-14 17:05 ` [PATCH v7 3/3] x86: Make the GDT remapping read-only on 64-bit Thomas Garnier
2017-03-14 17:05   ` [kernel-hardening] " Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-14 17:05   ` Thomas Garnier
2017-03-14 21:04   ` Pavel Machek
2017-03-14 21:04     ` [kernel-hardening] " Pavel Machek
2017-03-14 21:04     ` Pavel Machek
2017-03-14 21:04     ` Pavel Machek
2017-03-14 21:20     ` Thomas Garnier
2017-03-14 21:20       ` [kernel-hardening] " Thomas Garnier
2017-03-14 21:20       ` Thomas Garnier
2017-03-14 21:20       ` Thomas Garnier
2017-03-14 22:43       ` H. Peter Anvin
2017-03-14 22:43       ` H. Peter Anvin
2017-03-14 22:43         ` H. Peter Anvin
2017-03-14 21:20     ` Thomas Garnier
2017-03-14 21:04   ` Pavel Machek
2017-03-16 11:11   ` [tip:x86/mm] " tip-bot for Thomas Garnier
2017-03-14 17:05 ` [PATCH v7 3/3] " Thomas Garnier
2017-03-15 13:52 ` [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size Boris Ostrovsky
2017-03-15 13:52   ` [kernel-hardening] " Boris Ostrovsky
2017-03-15 13:52   ` Boris Ostrovsky
2017-03-15 13:52   ` Boris Ostrovsky
2017-03-15 13:52   ` Boris Ostrovsky
2017-03-15 13:52 ` Boris Ostrovsky
2017-03-16  8:10 ` Ingo Molnar
2017-03-16  8:10 ` Ingo Molnar
2017-03-16  8:10   ` [kernel-hardening] " Ingo Molnar
2017-03-16  8:10   ` Ingo Molnar
2017-03-16  8:10   ` Ingo Molnar
2017-03-16  8:10   ` Ingo Molnar
2017-03-16 15:33   ` Thomas Garnier [this message]
2017-03-16 15:33     ` [kernel-hardening] " Thomas Garnier
2017-03-16 15:33     ` Thomas Garnier
2017-03-16 15:33     ` Thomas Garnier
2017-03-17  7:34     ` Ingo Molnar
2017-03-17  7:34       ` [kernel-hardening] " Ingo Molnar
2017-03-17  7:34       ` Ingo Molnar
2017-03-17  7:34       ` Ingo Molnar
2017-03-17  7:34     ` Ingo Molnar
2017-03-16 15:33   ` Thomas Garnier
2017-03-16 11:10 ` [tip:x86/mm] x86/mm: Adapt MODULES_END based on fixmap " tip-bot for Thomas Garnier
  -- strict thread matches above, loose matches on Subject: below --
2017-03-14 17:05 [PATCH v7 1/3] x86/mm: Adapt MODULES_END based on Fixmap " Thomas Garnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcbSZEB09inR2KLF_puOnmAK7QUv-zJHcguiF0qucUYTtg1Pw@mail.gmail.com \
    --to=thgarnie@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=corbet@lwn.net \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jikos@kernel.org \
    --cc=keescook@chromium.org \
    --cc=len.brown@intel.com \
    --cc=lstoakes@gmail.com \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=matt@codeblueprint.co.uk \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=paul.gortmaker@windriver.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=zijun_hu@htc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.