[PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix

[PATCH v3 0/2] x86: SME: Kexec/kdump memory loading fix

[Lendacky, Thomas]

This series addresses an issue related to kexec/kdump when SME is active.
The SME support uses a workarea located after the end of the kernel to
perform "in-place" encryption of the kernel. When kexec/kdump is used, it
is possible that some other data used by kexec/kdump could be in this area
of memory which would cause the kexec/kdump of the kernel to fail.

Create a workarea section for use by SME in vmlinux.lds.S that is
positioned after "_end", so that the memory it occupies will be reclaimed
after its use during boot. Since it is part of the kernel image, there is
no worry now that kexec/kdump will place data in the SME workarea when
installing the kexec/kdump kernel. As part of this fix, clarify what
occupied kernel memory is reserved and what parts of the kernel memory are
discarded.

The following patches are included:
- Identify and document what parts of the kernel image are reserved
  (saved) and what is discarded.
- Create a new section that lives outside of the kernel proper, so that it
  will be reclaimed as available memory during boot, thus allowing it to
  be used as a workarea by SME for kernel in-place encryption during early
  boot..

This patch series is based on tip/master.

---

Changes from v2:
- Grammar fixes
- A more generic naming of the scratch/workarea section to indicate it
  is not restricted to SME usage

Changes from v1:
- Clarify how and where the kernel sections/memory is reserved.
- Add an explicit symbol, __end_of_kernel_reserve, for reserving the
  kernel memory rather than using __bss_stop.


Tom Lendacky (2):
  x86/mm: Identify the end of the kernel area to be reserved
  x86/mm: Create a workarea in the kernel for SME early encryption

 arch/x86/include/asm/sections.h    |  2 ++
 arch/x86/kernel/setup.c            |  8 ++++++-
 arch/x86/kernel/vmlinux.lds.S      | 34 +++++++++++++++++++++++++++++-
 arch/x86/mm/mem_encrypt_identity.c | 22 +++++++++++++++++--
 4 files changed, 62 insertions(+), 4 deletions(-)

-- 
2.17.1

[PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Lendacky, Thomas]

The memory occupied by the kernel is reserved using memblock_reserve()
in setup_arch(). Currently, the area is from symbols _text to __bss_stop.
Everything after __bss_stop must be specifically reserved otherwise it
is discarded. This is not clearly documented.

Add a new symbol, __end_of_kernel_reserve, that more readily identifies
what is reserved, along with comments that indicate what is reserved,
what is discarded and what needs to be done to prevent a section from
being discarded.

Tested-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/include/asm/sections.h | 2 ++
 arch/x86/kernel/setup.c         | 8 +++++++-
 arch/x86/kernel/vmlinux.lds.S   | 9 ++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 8ea1cfdbeabc..71b32f2570ab 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -13,4 +13,6 @@ extern char __end_rodata_aligned[];
 extern char __end_rodata_hpage_align[];
 #endif
 
+extern char __end_of_kernel_reserve[];
+
 #endif	/* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 08a5f4a131f5..fe0f6ebefeb7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -827,8 +827,14 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 
 void __init setup_arch(char **cmdline_p)
 {
+	/*
+	 * Reserve the memory occupied by the kernel between _text and
+	 * __end_of_kernel_reserve symbols. Any kernel sections after the
+	 * __end_of_kernel_reserve symbol must be explicity reserved with a
+	 * separate memblock_reserve() or they will be discarded.
+	 */
 	memblock_reserve(__pa_symbol(_text),
-			 (unsigned long)__bss_stop - (unsigned long)_text);
+			 (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);
 
 	/*
 	 * Make sure page 0 is always reserved because on systems with
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 0850b5149345..ca2252ca6ad7 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -368,6 +368,14 @@ SECTIONS
 		__bss_stop = .;
 	}
 
+	/*
+	 * The memory occupied from _text to here, __end_of_kernel_reserve, is
+	 * automatically reserved in setup_arch(). Anything after here must be
+	 * explicitly reserved using memblock_reserve() or it will be discarded
+	 * and treated as available memory.
+	 */
+	__end_of_kernel_reserve = .;
+
 	. = ALIGN(PAGE_SIZE);
 	.brk : AT(ADDR(.brk) - LOAD_OFFSET) {
 		__brk_base = .;
@@ -382,7 +390,6 @@ SECTIONS
 	STABS_DEBUG
 	DWARF_DEBUG
 
-	/* Sections to be discarded */
 	DISCARDS
 	/DISCARD/ : {
 		*(.eh_frame)
-- 
2.17.1

[PATCH v3 2/2] x86/mm: Create a workarea in the kernel for SME early encryption

[Lendacky, Thomas]

In order for the kernel to be encrypted "in place" during boot, a workarea
outside of the kernel must be used. This SME workarea used during early
encryption of the kernel is situated on a 2MB boundary after the end of
the kernel text, data, etc. sections (_end).  This works well during
initial boot of a compressed kernel because of the relocation used for
decompression of the kernel. But when performing a kexec boot, there's a
chance that the SME workarea may not be mapped by the kexec pagetables or
that some of the other data used by kexec could exist in this range.

Create a section for SME in vmlinux.lds.S. Position it after "_end", which
is after "__end_of_kernel_reserve", so that the memory will be reclaimed
during boot and since this area is all zeroes, it compresses well. This
new section will be part of the kernel image, so kexec will account for it
in pagetable mappings and placement of data after the kernel.

Here's an example of a kernel size without and with the SME section:
	without:
		vmlinux:	36,501,616
		bzImage:	 6,497,344

		100000000-47f37ffff : System RAM
		  1e4000000-1e47677d4 : Kernel code	(0x7677d4)
		  1e47677d5-1e4e2e0bf : Kernel data	(0x6c68ea)
		  1e5074000-1e5372fff : Kernel bss	(0x2fefff)

	with:
		vmlinux:	44,419,408
		bzImage:	 6,503,136

		880000000-c7ff7ffff : System RAM
		  8cf000000-8cf7677d4 : Kernel code	(0x7677d4)
		  8cf7677d5-8cfe2e0bf : Kernel data	(0x6c68ea)
		  8d0074000-8d0372fff : Kernel bss	(0x2fefff)

Tested-by: Lianbo Jiang <lijiang@redhat.com>
Reviewed-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
 arch/x86/kernel/vmlinux.lds.S      | 25 +++++++++++++++++++++++++
 arch/x86/mm/mem_encrypt_identity.c | 22 ++++++++++++++++++++--
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index ca2252ca6ad7..147cd020516a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -387,6 +387,31 @@ SECTIONS
 	. = ALIGN(PAGE_SIZE);		/* keep VO_INIT_SIZE page aligned */
 	_end = .;
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+	/*
+	 * Early scratch/workarea section: Lives outside of the kernel proper
+	 * (_text - _end).
+	 *
+	 * Resides after _end because even though the .brk section is after
+	 * __end_of_kernel_reserve, the .brk section is later reserved as a
+	 * part of the kernel. Since it is located after __end_of_kernel_reserve
+	 * it will be discarded and become part of the available memory. As
+	 * such, it can only be used by very early boot code and must not be
+	 * needed afterwards.
+	 *
+	 * Currently used by SME for performing in-place encryption of the
+	 * kernel during boot. Resides on a 2MB boundary to simplify the
+	 * pagetable setup used for SME in-place encryption.
+	 */
+	. = ALIGN(HPAGE_SIZE);
+	.init.scratch : AT(ADDR(.init.scratch) - LOAD_OFFSET) {
+		__init_scratch_begin = .;
+		*(.init.scratch)
+		. = ALIGN(HPAGE_SIZE);
+		__init_scratch_end = .;
+	}
+#endif
+
 	STABS_DEBUG
 	DWARF_DEBUG
 
diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c
index 4aa9b1480866..6a8dd483f7d9 100644
--- a/arch/x86/mm/mem_encrypt_identity.c
+++ b/arch/x86/mm/mem_encrypt_identity.c
@@ -73,6 +73,19 @@ struct sme_populate_pgd_data {
 	unsigned long vaddr_end;
 };
 
+/*
+ * This work area lives in the .init.scratch section, which lives outside of
+ * the kernel proper. It is sized to hold the intermediate copy buffer and
+ * more than enough pagetable pages.
+ *
+ * By using this section, the kernel can be encrypted in place and it
+ * avoids any possibility of boot parameters or initramfs images being
+ * placed such that the in-place encryption logic overwrites them.  This
+ * section is 2MB aligned to allow for simple pagetable setup using only
+ * PMD entries (see vmlinux.lds.S).
+ */
+static char sme_workarea[2 * PMD_PAGE_SIZE] __section(.init.scratch);
+
 static char sme_cmdline_arg[] __initdata = "mem_encrypt";
 static char sme_cmdline_on[]  __initdata = "on";
 static char sme_cmdline_off[] __initdata = "off";
@@ -314,8 +327,13 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
 	}
 #endif
 
-	/* Set the encryption workarea to be immediately after the kernel */
-	workarea_start = kernel_end;
+	/*
+	 * We're running identity mapped, so we must obtain the address to the
+	 * SME encryption workarea using rip-relative addressing.
+	 */
+	asm ("lea sme_workarea(%%rip), %0"
+	     : "=r" (workarea_start)
+	     : "p" (sme_workarea));
 
 	/*
 	 * Calculate required number of workarea bytes needed:
-- 
2.17.1

[tip:x86/kdump] x86/mm: Identify the end of the kernel area to be reserved

[tip-bot for Thomas Lendacky]

Commit-ID:  c603a309cc75f3dd018ddb20ee44c05047918cbf
Gitweb:     https://git.kernel.org/tip/c603a309cc75f3dd018ddb20ee44c05047918cbf
Author:     Thomas Lendacky <Thomas.Lendacky@amd.com>
AuthorDate: Wed, 19 Jun 2019 18:40:57 +0000
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Thu, 20 Jun 2019 09:22:47 +0200

x86/mm: Identify the end of the kernel area to be reserved

The memory occupied by the kernel is reserved using memblock_reserve()
in setup_arch(). Currently, the area is from symbols _text to __bss_stop.
Everything after __bss_stop must be specifically reserved otherwise it
is discarded. This is not clearly documented.

Add a new symbol, __end_of_kernel_reserve, that more readily identifies
what is reserved, along with comments that indicate what is reserved,
what is discarded and what needs to be done to prevent a section from
being discarded.

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Tested-by: Lianbo Jiang <lijiang@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <rrichter@marvell.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Sinan Kaya <okaya@codeaurora.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "x86@kernel.org" <x86@kernel.org>
Link: https://lkml.kernel.org/r/7db7da45b435f8477f25e66f292631ff766a844c.1560969363.git.thomas.lendacky@amd.com
---
 arch/x86/include/asm/sections.h | 2 ++
 arch/x86/kernel/setup.c         | 8 +++++++-
 arch/x86/kernel/vmlinux.lds.S   | 9 ++++++++-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/sections.h b/arch/x86/include/asm/sections.h
index 8ea1cfdbeabc..71b32f2570ab 100644
--- a/arch/x86/include/asm/sections.h
+++ b/arch/x86/include/asm/sections.h
@@ -13,4 +13,6 @@ extern char __end_rodata_aligned[];
 extern char __end_rodata_hpage_align[];
 #endif
 
+extern char __end_of_kernel_reserve[];
+
 #endif	/* _ASM_X86_SECTIONS_H */
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 08a5f4a131f5..dac60ad37e5e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -827,8 +827,14 @@ dump_kernel_offset(struct notifier_block *self, unsigned long v, void *p)
 
 void __init setup_arch(char **cmdline_p)
 {
+	/*
+	 * Reserve the memory occupied by the kernel between _text and
+	 * __end_of_kernel_reserve symbols. Any kernel sections after the
+	 * __end_of_kernel_reserve symbol must be explicitly reserved with a
+	 * separate memblock_reserve() or they will be discarded.
+	 */
 	memblock_reserve(__pa_symbol(_text),
-			 (unsigned long)__bss_stop - (unsigned long)_text);
+			 (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);
 
 	/*
 	 * Make sure page 0 is always reserved because on systems with
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 0850b5149345..ca2252ca6ad7 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -368,6 +368,14 @@ SECTIONS
 		__bss_stop = .;
 	}
 
+	/*
+	 * The memory occupied from _text to here, __end_of_kernel_reserve, is
+	 * automatically reserved in setup_arch(). Anything after here must be
+	 * explicitly reserved using memblock_reserve() or it will be discarded
+	 * and treated as available memory.
+	 */
+	__end_of_kernel_reserve = .;
+
 	. = ALIGN(PAGE_SIZE);
 	.brk : AT(ADDR(.brk) - LOAD_OFFSET) {
 		__brk_base = .;
@@ -382,7 +390,6 @@ SECTIONS
 	STABS_DEBUG
 	DWARF_DEBUG
 
-	/* Sections to be discarded */
 	DISCARDS
 	/DISCARD/ : {
 		*(.eh_frame)

[tip:x86/kdump] x86/mm: Create a workarea in the kernel for SME early encryption

[tip-bot for Thomas Lendacky]

Commit-ID:  e1bfa87399e372446454ecbaeba2800f0a385733
Gitweb:     https://git.kernel.org/tip/e1bfa87399e372446454ecbaeba2800f0a385733
Author:     Thomas Lendacky <Thomas.Lendacky@amd.com>
AuthorDate: Wed, 19 Jun 2019 18:40:59 +0000
Committer:  Borislav Petkov <bp@suse.de>
CommitDate: Thu, 20 Jun 2019 09:44:26 +0200

x86/mm: Create a workarea in the kernel for SME early encryption

In order for the kernel to be encrypted "in place" during boot, a workarea
outside of the kernel must be used. This SME workarea used during early
encryption of the kernel is situated on a 2MB boundary after the end of
the kernel text, data, etc. sections (_end).

This works well during initial boot of a compressed kernel because of
the relocation used for decompression of the kernel. But when performing
a kexec boot, there's a chance that the SME workarea may not be mapped
by the kexec pagetables or that some of the other data used by kexec
could exist in this range.

Create a section for SME in vmlinux.lds.S. Position it after "_end", which
is after "__end_of_kernel_reserve", so that the memory will be reclaimed
during boot and since this area is all zeroes, it compresses well. This
new section will be part of the kernel image, so kexec will account for it
in pagetable mappings and placement of data after the kernel.

Here's an example of a kernel size without and with the SME section:

	without:
		vmlinux:	36,501,616
		bzImage:	 6,497,344

		100000000-47f37ffff : System RAM
		  1e4000000-1e47677d4 : Kernel code	(0x7677d4)
		  1e47677d5-1e4e2e0bf : Kernel data	(0x6c68ea)
		  1e5074000-1e5372fff : Kernel bss	(0x2fefff)

	with:
		vmlinux:	44,419,408
		bzImage:	 6,503,136

		880000000-c7ff7ffff : System RAM
		  8cf000000-8cf7677d4 : Kernel code	(0x7677d4)
		  8cf7677d5-8cfe2e0bf : Kernel data	(0x6c68ea)
		  8d0074000-8d0372fff : Kernel bss	(0x2fefff)

Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Dave Hansen <dave.hansen@intel.com>
Tested-by: Lianbo Jiang <lijiang@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael Ávila de Espíndola" <rafael@espindo.la>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "x86@kernel.org" <x86@kernel.org>
Link: https://lkml.kernel.org/r/3c483262eb4077b1654b2052bd14a8d011bffde3.1560969363.git.thomas.lendacky@amd.com
---
 arch/x86/kernel/vmlinux.lds.S      | 25 +++++++++++++++++++++++++
 arch/x86/mm/mem_encrypt_identity.c | 22 ++++++++++++++++++++--
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index ca2252ca6ad7..147cd020516a 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -387,6 +387,31 @@ SECTIONS
 	. = ALIGN(PAGE_SIZE);		/* keep VO_INIT_SIZE page aligned */
 	_end = .;
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+	/*
+	 * Early scratch/workarea section: Lives outside of the kernel proper
+	 * (_text - _end).
+	 *
+	 * Resides after _end because even though the .brk section is after
+	 * __end_of_kernel_reserve, the .brk section is later reserved as a
+	 * part of the kernel. Since it is located after __end_of_kernel_reserve
+	 * it will be discarded and become part of the available memory. As
+	 * such, it can only be used by very early boot code and must not be
+	 * needed afterwards.
+	 *
+	 * Currently used by SME for performing in-place encryption of the
+	 * kernel during boot. Resides on a 2MB boundary to simplify the
+	 * pagetable setup used for SME in-place encryption.
+	 */
+	. = ALIGN(HPAGE_SIZE);
+	.init.scratch : AT(ADDR(.init.scratch) - LOAD_OFFSET) {
+		__init_scratch_begin = .;
+		*(.init.scratch)
+		. = ALIGN(HPAGE_SIZE);
+		__init_scratch_end = .;
+	}
+#endif
+
 	STABS_DEBUG
 	DWARF_DEBUG
 
diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c
index 4aa9b1480866..6a8dd483f7d9 100644
--- a/arch/x86/mm/mem_encrypt_identity.c
+++ b/arch/x86/mm/mem_encrypt_identity.c
@@ -73,6 +73,19 @@ struct sme_populate_pgd_data {
 	unsigned long vaddr_end;
 };
 
+/*
+ * This work area lives in the .init.scratch section, which lives outside of
+ * the kernel proper. It is sized to hold the intermediate copy buffer and
+ * more than enough pagetable pages.
+ *
+ * By using this section, the kernel can be encrypted in place and it
+ * avoids any possibility of boot parameters or initramfs images being
+ * placed such that the in-place encryption logic overwrites them.  This
+ * section is 2MB aligned to allow for simple pagetable setup using only
+ * PMD entries (see vmlinux.lds.S).
+ */
+static char sme_workarea[2 * PMD_PAGE_SIZE] __section(.init.scratch);
+
 static char sme_cmdline_arg[] __initdata = "mem_encrypt";
 static char sme_cmdline_on[]  __initdata = "on";
 static char sme_cmdline_off[] __initdata = "off";
@@ -314,8 +327,13 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
 	}
 #endif
 
-	/* Set the encryption workarea to be immediately after the kernel */
-	workarea_start = kernel_end;
+	/*
+	 * We're running identity mapped, so we must obtain the address to the
+	 * SME encryption workarea using rip-relative addressing.
+	 */
+	asm ("lea sme_workarea(%%rip), %0"
+	     : "=r" (workarea_start)
+	     : "p" (sme_workarea));
 
 	/*
 	 * Calculate required number of workarea bytes needed:

[PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

Hi

This appears to be causing issues with gold again:

axion /usr/src/linux # make
  CALL    scripts/checksyscalls.sh
  CALL    scripts/atomic/check-atomics.sh
  DESCEND  objtool
  CHK     include/generated/compile.h
  VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg
  VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg
  CHK     kernel/kheaders_data.tar.xz
  CC      arch/x86/boot/compressed/misc.o
  RELOCS  arch/x86/boot/compressed/vmlinux.relocs
Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
make: *** [arch/x86/Makefile:316: bzImage] Error 2

Here's the version I'm running:

sys-devel/gcc-9.1.0-r1 
sys-libs/glibc-2.29-r2 
sys-devel/binutils-2.32-r1

Cheers

Mike

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Sat, 13 Jul 2019, Mike Lothian wrote:

> This appears to be causing issues with gold again:
> 
> axion /usr/src/linux # make
>   CALL    scripts/checksyscalls.sh
>   CALL    scripts/atomic/check-atomics.sh
>   DESCEND  objtool
>   CHK     include/generated/compile.h
>   VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg
>   VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg
>   CHK     kernel/kheaders_data.tar.xz
>   CC      arch/x86/boot/compressed/misc.o
>   RELOCS  arch/x86/boot/compressed/vmlinux.relocs
> Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
> make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> make: *** [arch/x86/Makefile:316: bzImage] Error 2

That's fixed upstream already.

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

Will the fix be in the next RC?

On Sun, 14 Jul 2019 at 11:16, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sat, 13 Jul 2019, Mike Lothian wrote:
>
> > This appears to be causing issues with gold again:
> >
> > axion /usr/src/linux # make
> >   CALL    scripts/checksyscalls.sh
> >   CALL    scripts/atomic/check-atomics.sh
> >   DESCEND  objtool
> >   CHK     include/generated/compile.h
> >   VDSOCHK arch/x86/entry/vdso/vdso64.so.dbg
> >   VDSOCHK arch/x86/entry/vdso/vdso32.so.dbg
> >   CHK     kernel/kheaders_data.tar.xz
> >   CC      arch/x86/boot/compressed/misc.o
> >   RELOCS  arch/x86/boot/compressed/vmlinux.relocs
> > Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
> > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> > make: *** [arch/x86/Makefile:316: bzImage] Error 2
>
> That's fixed upstream already.
>
> Thanks,
>
>         tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Sun, 14 Jul 2019, Mike Lothian wrote:

> Will the fix be in the next RC?

As I said, it's upstream already, so yes.
 

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Mon, 15 Jul 2019, Mike Lothian wrote:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

> That build failure is from the current tip of Linus's tree
> 
> If the fix is in, then it hasn't fixed the issue

Sorry, my bad. There was a very similar issue and I confused the two:

  013c66edf207 ("Revert "x86/build: Move _etext to actual end of .text"")

The reverted commit caused a build fail with gold as well. Let me stare at
your issue.

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Mon, 15 Jul 2019, Thomas Gleixner wrote:
> On Mon, 15 Jul 2019, Mike Lothian wrote:
> > That build failure is from the current tip of Linus's tree
> > If the fix is in, then it hasn't fixed the issue
> 
> The reverted commit caused a build fail with gold as well. Let me stare at
> your issue.

So with gold the build fails in the reloc tool complaining about that
relocation:

  Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve

The commit does:
 
+extern char __end_of_kernel_reserve[];
+
 
 void __init setup_arch(char **cmdline_p)
 {
+	/*
+	 * Reserve the memory occupied by the kernel between _text and
+	 * __end_of_kernel_reserve symbols. Any kernel sections after the
+	 * __end_of_kernel_reserve symbol must be explicitly reserved with a
+	 * separate memblock_reserve() or they will be discarded.
+	 */
 	memblock_reserve(__pa_symbol(_text),
-			 (unsigned long)__bss_stop - (unsigned long)_text);
+			 (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);

So it replaces __bss_stop with __end_of_kernel_reserve here.

--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -368,6 +368,14 @@ SECTIONS
 		__bss_stop = .;
 	}
 
+	/*
+	 * The memory occupied from _text to here, __end_of_kernel_reserve, is
+	 * automatically reserved in setup_arch(). Anything after here must be
+	 * explicitly reserved using memblock_reserve() or it will be discarded
+	 * and treated as available memory.
+	 */
+	__end_of_kernel_reserve = .;

And from the linker script __bss_stop and __end_of_kernel_reserve are
exactly the same. From System.map (of a successful ld build):

ffffffff82c00000 B __brk_base
ffffffff82c00000 B __bss_stop
ffffffff82c00000 B __end_bss_decrypted
ffffffff82c00000 B __end_of_kernel_reserve
ffffffff82c00000 B __start_bss_decrypted
ffffffff82c00000 B __start_bss_decrypted_unused

So how on earth can gold fail with that __end_of_kernel_reserve change?

For some unknown reason it turns that relocation into an absolute
one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned
about that kind of behaviour.

If we just revert that commit, then what do we achieve? We paper over the
underlying problem, which is not really helping anything.

Aside of that gold still fails to build the X32 VDSO and it does so for a
very long time....

Until we really understand what the problem is, this stays as is.

@H.J.: Any insight on that?

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[H.J. Lu]

On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 15 Jul 2019, Thomas Gleixner wrote:
> > On Mon, 15 Jul 2019, Mike Lothian wrote:
> > > That build failure is from the current tip of Linus's tree
> > > If the fix is in, then it hasn't fixed the issue
> >
> > The reverted commit caused a build fail with gold as well. Let me stare at
> > your issue.
>
> So with gold the build fails in the reloc tool complaining about that
> relocation:
>
>   Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
>
> The commit does:
>
> +extern char __end_of_kernel_reserve[];
> +
>
>  void __init setup_arch(char **cmdline_p)
>  {
> +       /*
> +        * Reserve the memory occupied by the kernel between _text and
> +        * __end_of_kernel_reserve symbols. Any kernel sections after the
> +        * __end_of_kernel_reserve symbol must be explicitly reserved with a
> +        * separate memblock_reserve() or they will be discarded.
> +        */
>         memblock_reserve(__pa_symbol(_text),
> -                        (unsigned long)__bss_stop - (unsigned long)_text);
> +                        (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);
>
> So it replaces __bss_stop with __end_of_kernel_reserve here.
>
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -368,6 +368,14 @@ SECTIONS
>                 __bss_stop = .;
>         }
>
> +       /*
> +        * The memory occupied from _text to here, __end_of_kernel_reserve, is
> +        * automatically reserved in setup_arch(). Anything after here must be
> +        * explicitly reserved using memblock_reserve() or it will be discarded
> +        * and treated as available memory.
> +        */
> +       __end_of_kernel_reserve = .;
>
> And from the linker script __bss_stop and __end_of_kernel_reserve are
> exactly the same. From System.map (of a successful ld build):
>
> ffffffff82c00000 B __brk_base
> ffffffff82c00000 B __bss_stop
> ffffffff82c00000 B __end_bss_decrypted
> ffffffff82c00000 B __end_of_kernel_reserve
> ffffffff82c00000 B __start_bss_decrypted
> ffffffff82c00000 B __start_bss_decrypted_unused
>
> So how on earth can gold fail with that __end_of_kernel_reserve change?
>
> For some unknown reason it turns that relocation into an absolute
> one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned
> about that kind of behaviour.
>
> If we just revert that commit, then what do we achieve? We paper over the
> underlying problem, which is not really helping anything.
>
> Aside of that gold still fails to build the X32 VDSO and it does so for a
> very long time....
>
> Until we really understand what the problem is, this stays as is.
>
> @H.J.: Any insight on that?
>

Since building a workable kernel for different kernel configurations isn't a
requirement for gold, I don't recommend gold for kernel.

-- 
H.J.

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote:
> On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > On Mon, 15 Jul 2019, Thomas Gleixner wrote:
> > > On Mon, 15 Jul 2019, Mike Lothian wrote:
> > > > That build failure is from the current tip of Linus's tree
> > > > If the fix is in, then it hasn't fixed the issue
> > >
> > > The reverted commit caused a build fail with gold as well. Let me stare at
> > > your issue.
> >
> > So with gold the build fails in the reloc tool complaining about that
> > relocation:
> >
> >   Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
> >
> > The commit does:
> >
> > +extern char __end_of_kernel_reserve[];
> > +
> >
> >  void __init setup_arch(char **cmdline_p)
> >  {
> > +       /*
> > +        * Reserve the memory occupied by the kernel between _text and
> > +        * __end_of_kernel_reserve symbols. Any kernel sections after the
> > +        * __end_of_kernel_reserve symbol must be explicitly reserved with a
> > +        * separate memblock_reserve() or they will be discarded.
> > +        */
> >         memblock_reserve(__pa_symbol(_text),
> > -                        (unsigned long)__bss_stop - (unsigned long)_text);
> > +                        (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);
> >
> > So it replaces __bss_stop with __end_of_kernel_reserve here.
> >
> > --- a/arch/x86/kernel/vmlinux.lds.S
> > +++ b/arch/x86/kernel/vmlinux.lds.S
> > @@ -368,6 +368,14 @@ SECTIONS
> >                 __bss_stop = .;
> >         }
> >
> > +       /*
> > +        * The memory occupied from _text to here, __end_of_kernel_reserve, is
> > +        * automatically reserved in setup_arch(). Anything after here must be
> > +        * explicitly reserved using memblock_reserve() or it will be discarded
> > +        * and treated as available memory.
> > +        */
> > +       __end_of_kernel_reserve = .;
> >
> > And from the linker script __bss_stop and __end_of_kernel_reserve are
> > exactly the same. From System.map (of a successful ld build):
> >
> > ffffffff82c00000 B __brk_base
> > ffffffff82c00000 B __bss_stop
> > ffffffff82c00000 B __end_bss_decrypted
> > ffffffff82c00000 B __end_of_kernel_reserve
> > ffffffff82c00000 B __start_bss_decrypted
> > ffffffff82c00000 B __start_bss_decrypted_unused
> >
> > So how on earth can gold fail with that __end_of_kernel_reserve change?
> >
> > For some unknown reason it turns that relocation into an absolute
> > one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned
> > about that kind of behaviour.
> >
> > If we just revert that commit, then what do we achieve? We paper over the
> > underlying problem, which is not really helping anything.
> >
> > Aside of that gold still fails to build the X32 VDSO and it does so for a
> > very long time....
> >
> > Until we really understand what the problem is, this stays as is.
> >
> > @H.J.: Any insight on that?
> >
> 
> Since building a workable kernel for different kernel configurations isn't a
> requirement for gold, I don't recommend gold for kernel.

Um, it worked before this commit, and now it doesn't.  "Some" companies
are using gold for linking the kernel today...

thanks,

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Tue, 23 Jul 2019, Greg KH wrote:
> On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote:
> > >
> > 
> > Since building a workable kernel for different kernel configurations isn't a
> > requirement for gold, I don't recommend gold for kernel.
> 
> Um, it worked before this commit, and now it doesn't.  "Some" companies
> are using gold for linking the kernel today...

gold is known to fail the kernel build. x32 vdso linking is not working
since years and just because it 'works' for some configurations and breaks
for no valid reasons even with those configurations is just not good
enough.

As there is obviously no priority for fixing gold to work proper with the
kernel, I'm not at all interested in these 'regression' reports and in odd
'fixes' which just end up reverting or modifying perfectly valid changes
without understanding the root cause, i.e. the most horrible engineering
principle: duct-taping.

TBH, I'm tired of it. We fail the build for clang if it does not support
asm gotos and the clang people are actively working on fixing it and we're
helping them as much as we can. The companies who used clang nevertheless
have been on their own for years and if someone wants to use gold then
nobody is preventing them from doing so. They can keep their duct-tape in
their own trees.

See this thread for further discussion:

 https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Tue, Jul 23, 2019 at 03:05:14PM +0200, Greg KH wrote:
> On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote:
> > On Mon, Jul 15, 2019 at 3:35 AM Thomas Gleixner <tglx@linutronix.de> wrote:
> > >
> > > On Mon, 15 Jul 2019, Thomas Gleixner wrote:
> > > > On Mon, 15 Jul 2019, Mike Lothian wrote:
> > > > > That build failure is from the current tip of Linus's tree
> > > > > If the fix is in, then it hasn't fixed the issue
> > > >
> > > > The reverted commit caused a build fail with gold as well. Let me stare at
> > > > your issue.
> > >
> > > So with gold the build fails in the reloc tool complaining about that
> > > relocation:
> > >
> > >   Invalid absolute R_X86_64_32S relocation: __end_of_kernel_reserve
> > >
> > > The commit does:
> > >
> > > +extern char __end_of_kernel_reserve[];
> > > +
> > >
> > >  void __init setup_arch(char **cmdline_p)
> > >  {
> > > +       /*
> > > +        * Reserve the memory occupied by the kernel between _text and
> > > +        * __end_of_kernel_reserve symbols. Any kernel sections after the
> > > +        * __end_of_kernel_reserve symbol must be explicitly reserved with a
> > > +        * separate memblock_reserve() or they will be discarded.
> > > +        */
> > >         memblock_reserve(__pa_symbol(_text),
> > > -                        (unsigned long)__bss_stop - (unsigned long)_text);
> > > +                        (unsigned long)__end_of_kernel_reserve - (unsigned long)_text);
> > >
> > > So it replaces __bss_stop with __end_of_kernel_reserve here.
> > >
> > > --- a/arch/x86/kernel/vmlinux.lds.S
> > > +++ b/arch/x86/kernel/vmlinux.lds.S
> > > @@ -368,6 +368,14 @@ SECTIONS
> > >                 __bss_stop = .;
> > >         }
> > >
> > > +       /*
> > > +        * The memory occupied from _text to here, __end_of_kernel_reserve, is
> > > +        * automatically reserved in setup_arch(). Anything after here must be
> > > +        * explicitly reserved using memblock_reserve() or it will be discarded
> > > +        * and treated as available memory.
> > > +        */
> > > +       __end_of_kernel_reserve = .;
> > >
> > > And from the linker script __bss_stop and __end_of_kernel_reserve are
> > > exactly the same. From System.map (of a successful ld build):
> > >
> > > ffffffff82c00000 B __brk_base
> > > ffffffff82c00000 B __bss_stop
> > > ffffffff82c00000 B __end_bss_decrypted
> > > ffffffff82c00000 B __end_of_kernel_reserve
> > > ffffffff82c00000 B __start_bss_decrypted
> > > ffffffff82c00000 B __start_bss_decrypted_unused
> > >
> > > So how on earth can gold fail with that __end_of_kernel_reserve change?
> > >
> > > For some unknown reason it turns that relocation into an absolute
> > > one. That's clearly a gold bug^Wfeature and TBH, I'm more than concerned
> > > about that kind of behaviour.
> > >
> > > If we just revert that commit, then what do we achieve? We paper over the
> > > underlying problem, which is not really helping anything.
> > >
> > > Aside of that gold still fails to build the X32 VDSO and it does so for a
> > > very long time....
> > >
> > > Until we really understand what the problem is, this stays as is.
> > >
> > > @H.J.: Any insight on that?
> > >
> > 
> > Since building a workable kernel for different kernel configurations isn't a
> > requirement for gold, I don't recommend gold for kernel.
> 
> Um, it worked before this commit, and now it doesn't.  "Some" companies
> are using gold for linking the kernel today...

Oh nevermind, I see the rest of the thread where it's now not being
allowed, sorry for the noise.

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Tue, Jul 23, 2019 at 03:31:32PM +0200, Thomas Gleixner wrote:
> On Tue, 23 Jul 2019, Greg KH wrote:
> > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote:
> > > >
> > > 
> > > Since building a workable kernel for different kernel configurations isn't a
> > > requirement for gold, I don't recommend gold for kernel.
> > 
> > Um, it worked before this commit, and now it doesn't.  "Some" companies
> > are using gold for linking the kernel today...
> 
> gold is known to fail the kernel build. x32 vdso linking is not working
> since years and just because it 'works' for some configurations and breaks
> for no valid reasons even with those configurations is just not good
> enough.
> 
> As there is obviously no priority for fixing gold to work proper with the
> kernel, I'm not at all interested in these 'regression' reports and in odd
> 'fixes' which just end up reverting or modifying perfectly valid changes
> without understanding the root cause, i.e. the most horrible engineering
> principle: duct-taping.
> 
> TBH, I'm tired of it. We fail the build for clang if it does not support
> asm gotos and the clang people are actively working on fixing it and we're
> helping them as much as we can. The companies who used clang nevertheless
> have been on their own for years and if someone wants to use gold then
> nobody is preventing them from doing so. They can keep their duct-tape in
> their own trees.
> 
> See this thread for further discussion:
> 
>  https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de

Sorry, I saw that after writing that.  You are right, if the others
don't object, that's fine with me.  I'll go poke the various build
systems that are failing right now on 5.3-rc1 and try to get them fixed
for this reason.

thanks,

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote:
> On Tue, Jul 23, 2019 at 03:31:32PM +0200, Thomas Gleixner wrote:
> > On Tue, 23 Jul 2019, Greg KH wrote:
> > > On Mon, Jul 15, 2019 at 01:16:48PM -0700, H.J. Lu wrote:
> > > > >
> > > > 
> > > > Since building a workable kernel for different kernel configurations isn't a
> > > > requirement for gold, I don't recommend gold for kernel.
> > > 
> > > Um, it worked before this commit, and now it doesn't.  "Some" companies
> > > are using gold for linking the kernel today...
> > 
> > gold is known to fail the kernel build. x32 vdso linking is not working
> > since years and just because it 'works' for some configurations and breaks
> > for no valid reasons even with those configurations is just not good
> > enough.
> > 
> > As there is obviously no priority for fixing gold to work proper with the
> > kernel, I'm not at all interested in these 'regression' reports and in odd
> > 'fixes' which just end up reverting or modifying perfectly valid changes
> > without understanding the root cause, i.e. the most horrible engineering
> > principle: duct-taping.
> > 
> > TBH, I'm tired of it. We fail the build for clang if it does not support
> > asm gotos and the clang people are actively working on fixing it and we're
> > helping them as much as we can. The companies who used clang nevertheless
> > have been on their own for years and if someone wants to use gold then
> > nobody is preventing them from doing so. They can keep their duct-tape in
> > their own trees.
> > 
> > See this thread for further discussion:
> > 
> >  https://lkml.kernel.org/r/alpine.DEB.2.21.1907161434260.1767@nanos.tec.linutronix.de
> 
> Sorry, I saw that after writing that.  You are right, if the others
> don't object, that's fine with me.  I'll go poke the various build
> systems that are failing right now on 5.3-rc1 and try to get them fixed
> for this reason.

Ok, I dug around and the gold linker is not being used here, only clang
to build the source and GNU ld to link, and I am still seeing this
error.

Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
the people who are providing this version of clang to see if there's
something they can figure out.

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Wed, 24 Jul 2019, Greg KH wrote:
> On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote:
> > Sorry, I saw that after writing that.  You are right, if the others
> > don't object, that's fine with me.  I'll go poke the various build
> > systems that are failing right now on 5.3-rc1 and try to get them fixed
> > for this reason.
> 
> Ok, I dug around and the gold linker is not being used here, only clang
> to build the source and GNU ld to link, and I am still seeing this
> error.

Odd combo.
 
> Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
> the people who are providing this version of clang to see if there's
> something they can figure out.

Let me try that with my clang variant. Which version of GNU ld are you
using?

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Greg KH wrote:
> > On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote:
> > > Sorry, I saw that after writing that.  You are right, if the others
> > > don't object, that's fine with me.  I'll go poke the various build
> > > systems that are failing right now on 5.3-rc1 and try to get them fixed
> > > for this reason.
> > 
> > Ok, I dug around and the gold linker is not being used here, only clang
> > to build the source and GNU ld to link, and I am still seeing this
> > error.
> 
> Odd combo.

I'm not disagreeing :)

Wait, does clang link things itself and not need ld?

> > Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
> > the people who are providing this version of clang to see if there's
> > something they can figure out.
> 
> Let me try that with my clang variant. Which version of GNU ld are you
> using?

I think it is 2.27:
$ ./ld --version
GNU ld (binutils-2.27-44492f8) 2.27.0.20170315

Which does feel old to me.

I know 2.32 works fine.

Gotta love old tool-chains :(

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Wed, 24 Jul 2019, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Greg KH wrote:
> > On Tue, Jul 23, 2019 at 03:44:54PM +0200, Greg KH wrote:
> > > Sorry, I saw that after writing that.  You are right, if the others
> > > don't object, that's fine with me.  I'll go poke the various build
> > > systems that are failing right now on 5.3-rc1 and try to get them fixed
> > > for this reason.
> > 
> > Ok, I dug around and the gold linker is not being used here, only clang
> > to build the source and GNU ld to link, and I am still seeing this
> > error.
> 
> Odd combo.

Ha. Not really. I did not switch ld with LD=... so it's using the default GNU ld.

> > Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
> > the people who are providing this version of clang to see if there's
> > something they can figure out.
> 
> Let me try that with my clang variant. Which version of GNU ld are you
> using?

Works with a very recent build of the clang-9 branch and ld version 2.31.1

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Wed, 24 Jul 2019, Greg KH wrote:
> On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote:
> > > Ok, I dug around and the gold linker is not being used here, only clang
> > > to build the source and GNU ld to link, and I am still seeing this
> > > error.
> > 
> > Odd combo.
> 
> I'm not disagreeing :)
> 
> Wait, does clang link things itself and not need ld?

Nah.

> > > Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
> > > the people who are providing this version of clang to see if there's
> > > something they can figure out.
> > 
> > Let me try that with my clang variant. Which version of GNU ld are you
> > using?
> 
> I think it is 2.27:
> $ ./ld --version
> GNU ld (binutils-2.27-44492f8) 2.27.0.20170315
> 
> Which does feel old to me.
> 
> I know 2.32 works fine.

2.31 works fine as well.

> Gotta love old tool-chains :(

Oh yes. /me does archaeology to find a VM with old stuff

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Greg KH wrote:
> > On Wed, Jul 24, 2019 at 05:49:45PM +0200, Thomas Gleixner wrote:
> > > > Ok, I dug around and the gold linker is not being used here, only clang
> > > > to build the source and GNU ld to link, and I am still seeing this
> > > > error.
> > > 
> > > Odd combo.
> > 
> > I'm not disagreeing :)
> > 
> > Wait, does clang link things itself and not need ld?
> 
> Nah.
> 
> > > > Hm, clang 8 does not cause this error, but clang 9 does.  Let me go poke
> > > > the people who are providing this version of clang to see if there's
> > > > something they can figure out.
> > > 
> > > Let me try that with my clang variant. Which version of GNU ld are you
> > > using?
> > 
> > I think it is 2.27:
> > $ ./ld --version
> > GNU ld (binutils-2.27-44492f8) 2.27.0.20170315
> > 
> > Which does feel old to me.
> > 
> > I know 2.32 works fine.
> 
> 2.31 works fine as well.
> 
> > Gotta love old tool-chains :(
> 
> Oh yes. /me does archaeology to find a VM with old stuff

I can provide a binary if you can't find anything.

thanks,

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Peter Zijlstra]

On Wed, Jul 24, 2019 at 05:57:35PM +0200, Greg KH wrote:
> Wait, does clang link things itself and not need ld?

There's ld.lld; which might be used by your clang.

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Wed, 24 Jul 2019, Greg KH wrote:
> On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote:
> > > Gotta love old tool-chains :(
> > 
> > Oh yes. /me does archaeology to find a VM with old stuff
> 
> I can provide a binary if you can't find anything.

Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with
LD_PRELOAD it builds without failure.

ld.gold from that binutils version dies with a segfault on various files ...

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Wed, 24 Jul 2019, Thomas Gleixner wrote:

> On Wed, 24 Jul 2019, Greg KH wrote:
> > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote:
> > > > Gotta love old tool-chains :(
> > > 
> > > Oh yes. /me does archaeology to find a VM with old stuff
> > 
> > I can provide a binary if you can't find anything.
> 
> Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with
> LD_PRELOAD it builds without failure.
> 
> ld.gold from that binutils version dies with a segfault on various files ...

Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on
every other file.

Copied that config to the clang build directory and it causes the same
explosions with ld.bfd.

What a time waste...

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Greg KH]

On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote:
> On Wed, 24 Jul 2019, Thomas Gleixner wrote:
> 
> > On Wed, 24 Jul 2019, Greg KH wrote:
> > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote:
> > > > > Gotta love old tool-chains :(
> > > > 
> > > > Oh yes. /me does archaeology to find a VM with old stuff
> > > 
> > > I can provide a binary if you can't find anything.
> > 
> > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with
> > LD_PRELOAD it builds without failure.
> > 
> > ld.gold from that binutils version dies with a segfault on various files ...
> 
> Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on
> every other file.
> 
> Copied that config to the clang build directory and it causes the same
> explosions with ld.bfd.
> 
> What a time waste...
> 
> 
> 

Ugh, sorry about this.  I can't seem to track it down either, and at
this point am just going to punt and let the Android build people try to
figure it out as it is their custom build system that is failing at the
moment, only for x86, and if this single patch is reverted, it starts
working again.

voodo...

thanks,

greg k-h

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

On Thu, 25 Jul 2019 at 07:59, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 24, 2019 at 10:20:34PM +0200, Thomas Gleixner wrote:
> > On Wed, 24 Jul 2019, Thomas Gleixner wrote:
> >
> > > On Wed, 24 Jul 2019, Greg KH wrote:
> > > > On Wed, Jul 24, 2019 at 06:03:41PM +0200, Thomas Gleixner wrote:
> > > > > > Gotta love old tool-chains :(
> > > > >
> > > > > Oh yes. /me does archaeology to find a VM with old stuff
> > > >
> > > > I can provide a binary if you can't find anything.
> > >
> > > Found GNU ld (GNU Binutils for Debian) 2.25 and after fiddling with
> > > LD_PRELOAD it builds without failure.
> > >
> > > ld.gold from that binutils version dies with a segfault on various files ...
> >
> > Then tried that old ld.bfd with GCC8 and that causes ld.bfd to segfault on
> > every other file.
> >
> > Copied that config to the clang build directory and it causes the same
> > explosions with ld.bfd.
> >
> > What a time waste...
> >
> >
> >
>
> Ugh, sorry about this.  I can't seem to track it down either, and at
> this point am just going to punt and let the Android build people try to
> figure it out as it is their custom build system that is failing at the
> moment, only for x86, and if this single patch is reverted, it starts
> working again.
>
> voodo...
>
> thanks,
>
> greg k-h

As it's related. I've raised
https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the
relocatition I'm seeing since switching back to ld.bfd - is this safe
to ignore? I'm guessing this is why gold isn't working as it can't do
them

Cheers

Mike

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote:
>
> As it's related. I've raised
> https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the
> relocatition I'm seeing since switching back to ld.bfd - is this safe
> to ignore? I'm guessing this is why gold isn't working as it can't do
> them
>
> Cheers
>
> Mike

Sorry am I asking in the wrong place about this?

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Mon, 19 Aug 2019, Mike Lothian wrote:
> On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote:
> >
> > As it's related. I've raised
> > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the
> > relocatition I'm seeing since switching back to ld.bfd - is this safe
> > to ignore? I'm guessing this is why gold isn't working as it can't do
> > them
> 
> Sorry am I asking in the wrong place about this?

No, but I haven't come around to look at it. As your mail above is not
giving any useful information and requires to fire up a browser it got on
the back burner.

That bugzilla entry does not tell anything about the compiler involved, the
binutils version and the .config file. I'm really bad at guesswork and my
crystal ball got lost years ago :)

Care to give that information here by mail?

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

On Mon, 19 Aug 2019 at 14:08, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 19 Aug 2019, Mike Lothian wrote:
> > On Wed, 14 Aug 2019 at 12:09, Mike Lothian <mike@fireburn.co.uk> wrote:
> > >
> > > As it's related. I've raised
> > > https://bugzilla.kernel.org/show_bug.cgi?id=204495 about the
> > > relocatition I'm seeing since switching back to ld.bfd - is this safe
> > > to ignore? I'm guessing this is why gold isn't working as it can't do
> > > them
> >
> > Sorry am I asking in the wrong place about this?
>
> No, but I haven't come around to look at it. As your mail above is not
> giving any useful information and requires to fire up a browser it got on
> the back burner.
>
> That bugzilla entry does not tell anything about the compiler involved, the
> binutils version and the .config file. I'm really bad at guesswork and my
> crystal ball got lost years ago :)
>
> Care to give that information here by mail?
>
> Thanks,
>
>         tglx

Hi

I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but
I've just switched back to using ld.bfd based on this discussion

My .config can be found at:
https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip

Cheers

Mike

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Thomas Gleixner]

On Mon, 19 Aug 2019, Mike Lothian wrote:
>
> I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but
> I've just switched back to using ld.bfd based on this discussion
> 
> My .config can be found at:
> https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip

Does this combo successfully build 5.2 or is this a general problem?

Thanks,

	tglx

Re: [PATCH v3 1/2] x86/mm: Identify the end of the kernel area to be reserved

[Mike Lothian]

I've updated the bug some more with more info

I can't replicate this on RHEL7 with GCC 4.8.5 or GCC 7.3.1

My GCC is as follows:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-9.2.0/work/gcc-9.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/g++-v9
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls
--without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.2.0
p1' --disable-esp --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-systemtap
--enable-vtable-verify --enable-lto --with-isl
--disable-isl-version-check --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.2.0 (Gentoo 9.2.0 p1)

Could this be related to the --enable-default-ssp or --enable-default-pie?

On Mon, 19 Aug 2019 at 14:31, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Mon, 19 Aug 2019, Mike Lothian wrote:
> >
> > I'm using GCC 9.2, binutils 2.32. I used to use the gold linker but
> > I've just switched back to using ld.bfd based on this discussion
> >
> > My .config can be found at:
> > https://raw.githubusercontent.com/FireBurn/KernelStuff/master/dot_config_tip
>
> Does this combo successfully build 5.2 or is this a general problem?
>
> Thanks,
>
>         tglx