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