android-4.19 Cuttlefish x86 does not boot after LLVM commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74 #852

nathanchance · 2020-02-02T09:07:14Z

Background: I have started boot testing Android Cuttlefish to try and catch bugs before they hit Android through either upstream Linux or LLVM.

I do not really have a whole ton of information to offer up right now other than a git bisect and isolating the problem purely to CONFIG_LTO_CLANG (CONFIG_CFI_CLANG does not affect it). I do not see this problem with android-5.4 or android-mainline, which I suspect is because they are using ThinLTO.

llvm/llvm-project@5b22bcc

$ git bisect log
# bad: [c4b4c0c47c992e63fc0792d71bea82b6e6dcf0cd] [mlir] Expand shape functions in ShapeInference doc
# good: [f0654875fb240ed9d4b2718cfa5f5c7f9d9daef3] [gn build] Port f2af0607000
git bisect start 'origin/master' 'f0654875fb240ed9d4b2718cfa5f5c7f9d9daef3'
# bad: [200ac6c3d88a1816c7ea86d5cde85e115a809542] [llvm-objcopy][test] Fix tests when path contains "bar"
git bisect bad 200ac6c3d88a1816c7ea86d5cde85e115a809542
# good: [8bb9642fd7cda09449af5cb0cced220e57a0011a] [gn build] Port 601687bf731
git bisect good 8bb9642fd7cda09449af5cb0cced220e57a0011a
# good: [1d9e08ec35a5979f103b876f8dd2324f77db3f6e] [AMDGPU] Add file headers for few files where it is missing.
git bisect good 1d9e08ec35a5979f103b876f8dd2324f77db3f6e
# good: [17dbc6611df9044d779d85b3d545bd37e5dd5200] AMDGPU: Cleanup and fix SMRD offset handling
git bisect good 17dbc6611df9044d779d85b3d545bd37e5dd5200
# good: [84bd8511085891a7c5f413f2d54d3a31b98105aa] [GlobalISel][IRTranslator] When translating vector geps, splat the base pointer if required.
git bisect good 84bd8511085891a7c5f413f2d54d3a31b98105aa
# good: [d28763cad06e66651e1936756d3e28126b055abf] Replace 'AllowExplicit' bool with an enum. No functionality change.
git bisect good d28763cad06e66651e1936756d3e28126b055abf
# good: [5ae6554a1dcd2e39346030c06d364492901c9e8d] PR41991: Accept attributes on defaulted and deleted friends.
git bisect good 5ae6554a1dcd2e39346030c06d364492901c9e8d
# bad: [5b22bcc2b70d82c73ce5428170dcc2038a729d74] [X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local
git bisect bad 5b22bcc2b70d82c73ce5428170dcc2038a729d74
# good: [980517b3530ffb7faa1a23fdc007d78f5b45ae3c] [Concepts] Check function constraints before deducing auto return type
git bisect good 980517b3530ffb7faa1a23fdc007d78f5b45ae3c
# first bad commit: [5b22bcc2b70d82c73ce5428170dcc2038a729d74] [X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local

I do not have a super clean set of steps to reproduce this but I can at some point of the next couple of days. If you are familiar with building Android kernels using build.sh and the build config system and using Cuttlefish, it should be fairly easy to reproduce with an upstream version of LLVM.

Good dmesg.

Bad dmesg.

cc @MaskRay @samitolvanen

The text was updated successfully, but these errors were encountered:

MaskRay · 2020-02-02T09:27:52Z

(I have no experience building Android.)

Can you check disassembly of linked results before and at commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74?

nickdesaulniers · 2020-02-02T11:20:45Z

llvm/llvm-project@5b22bcc

nathanchance · 2020-02-02T19:18:24Z

@MaskRay when I get home from work tonight, I will tar up all of the artifacts from the build so you can inspect them.

nathanchance · 2020-02-03T02:34:43Z

~~Objects compiled without 5b22bcc2b70d82c73ce5428170dcc2038a729d74~~

~~Objects compiled with 5b22bcc2b70d82c73ce5428170dcc2038a729d74~~

~~Warning, they are each 750MB... Let me know if there is anything else I can do to help!~~

Links no longer valid due to next comment and to save me space :)

MaskRay · 2020-02-03T07:55:15Z

Every bitcode .o is different. This is due to:

.ident assembly directive. It can be turned off via CFLAGS=-Qn (you can compare gcc/clang -S -Qy)
DW_AT_producer in .debug_info. Pass -DLLVM_APPEND_VC_REV=off when building clang can strip the commit id. It will be simply DW_AT_producer ("clang version 11.0.0 "). With this, -Qn should be unnecessary.

@nathanchance Can you build android-4.19 Cuttlefish x86 with -DLLVM_APPEND_VC_REV=off clang?

(Before pushing the .foo$local change, I have tested our internal code base. All passed. So there may be some really weird thing.)

nathanchance · 2020-02-03T08:01:08Z

Yes, I will do so right now.

nathanchance · 2020-02-03T09:37:26Z

Alright, these objects should have been built with a version of clang built with -DLLVM_APPEND_VC_REV=off.

https://1drv.ms/u/s!AsQNYeB-IEbqhx0R58-gfhL42SO3?e=pEvHpr

Currently broken with clang-11 :( Link: ClangBuiltLinux/linux#852 Signed-off-by: Nathan Chancellor <[email protected]>

nickdesaulniers · 2020-05-05T23:31:42Z

now running into this with https://android-review.googlesource.com/c/kernel/common/+/1301638.

I wonder if this is related to #872, which also mentions 5b22bcc2b70d82c73ce5428170dcc2038a729d74?

@samitolvanen

I was pulling my hair out trying to debug ClangBuiltLinux/linux#852 since breakpoints I set were never hit. Sami Tolvanen (@samitolvanen) reminded me I need to disable KASLR via nokaslr kernel command line parameter. Separate out the -append string from QEMU_ARCH_ARGS, since we need to change it both for interactive and debug mode.

@samitolvanen

I was pulling my hair out trying to debug ClangBuiltLinux/linux#852 since breakpoints I set were never hit. Sami Tolvanen (@samitolvanen) reminded me I need to disable KASLR via nokaslr kernel command line parameter. Separate out the -append string from QEMU_ARCH_ARGS, since we need to change it both for interactive and debug mode.

nickdesaulniers · 2020-05-09T02:45:47Z

@samitolvanen and I are looking into this together. Posting a status update before we go into the weekend and I forget everything.

diff --git a/arch/x86/configs/gki_defconfig b/arch/x86/configs/gki_defconfig
index ea16bd5cd458..69a79310395f 100644
--- a/arch/x86/configs/gki_defconfig
+++ b/arch/x86/configs/gki_defconfig
@@ -54,7 +54,7 @@ CONFIG_PCI_MSI=y
 CONFIG_IA32_EMULATION=y
 CONFIG_JUMP_LABEL=y
 CONFIG_LTO_CLANG=y
-CONFIG_CFI_CLANG=y
+#CONFIG_CFI_CLANG=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_MODVERSIONS=y
diff --git a/kernel/Makefile b/kernel/Makefile
index 278153bc4604..96d9d729d4c6 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -12,6 +12,8 @@ obj-y     = fork.o exec_domain.o panic.o \
            notifier.o ksysfs.o cred.o reboot.o \
            async.o range.o smpboot.o ucount.o
 
+subdir-ccflags-y += $(DISABLE_LTO)
+
 obj-$(CONFIG_MODULES) += kmod.o
 obj-$(CONFIG_MULTIUSER) += groups.o

allows this to boot. From here, we can narrow this down further to:

which object file[s]
which functions via outlining to TUs that do/don't have LTO enabled
which parts of code (via outlining + __attribute__((no_inlining))

nickdesaulniers · 2020-05-12T00:15:36Z

@samitolvanen has narrowed it down to kernel/time/timer.c.

If I move the definition of jiffies_64 into its own TU, and disable LTO there, it boots.

nickdesaulniers · 2020-05-13T21:56:06Z

fix in hand, will post upstream

nickdesaulniers · 2020-05-13T22:18:07Z

comments before sending upstream? : https://android-review.googlesource.com/c/kernel/common/+/1310377

nathanchance · 2020-05-15T05:58:39Z

Seems to make sense to me.

nickdesaulniers · 2020-05-15T18:19:02Z

submitted: https://lore.kernel.org/lkml/[email protected]/T/#u

`jiffies` and `jiffies_64` are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all arch's in: include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c for all arch's. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via `jiffies_64 = jiffies;`. As Fangrui notes: ``` In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. ``` So we have an ODR violation (UB), which we seem to have gotten away with thus far. Where it becomes harmful is when we: 1. Use -fno-semantic-interposition. As Fangrui notes: ``` Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. ``` This causes references to jiffies to refer to `.Ljiffies$local` when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to `.Ljiffies_64$local` in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. Combined with ... 2. Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to `jiffies_64` anywhere to replace with `jiffies`. And thus `.Ljiffies$local` and `.Ljiffies_64$local` no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, we observe spooky bugs where the kernel appeared to boot, but init doesn't get scheduled. Instead, we can avoid the ODR violation by matching other arch's by defining jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Link: ClangBuiltLinux#852 Fixes: 40747ff ("asmlinkage: Make jiffies visible") Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Suggested-by: Fangrui Song <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Signed-off-by: Bob Haarman <[email protected]>

`jiffies` and `jiffies_64` are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all arch's in: include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c for all arch's. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via `jiffies_64 = jiffies;`. As Fangrui notes: ``` In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. ``` So we have an ODR violation (UB), which we seem to have gotten away with thus far. Where it becomes harmful is when we: 1. Use -fno-semantic-interposition. As Fangrui notes: ``` Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. ``` This causes references to jiffies to refer to `.Ljiffies$local` when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to `.Ljiffies_64$local` in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. Combined with ... 2. Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to `jiffies_64` anywhere to replace with `jiffies`. And thus `.Ljiffies$local` and `.Ljiffies_64$local` no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, we observe spooky bugs where the kernel appeared to boot, but init doesn't get scheduled. Instead, we can avoid the ODR violation by matching other arch's by defining jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Link: ClangBuiltLinux/linux#852 Fixes: 40747ff ("asmlinkage: Make jiffies visible") Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Suggested-by: Fangrui Song <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Signed-off-by: Bob Haarman <[email protected]> (am from https://lore.kernel.org/lkml/[email protected]/T/#u) Bug: 155426344 Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: I337ddcffe71955eba4f6d2bfc8137e8262ece1d9

`jiffies` and `jiffies_64` are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all arch's in: include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c for all arch's. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via `jiffies_64 = jiffies;`. As Fangrui notes: ``` In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. ``` So we have an ODR violation (UB), which we seem to have gotten away with thus far. Where it becomes harmful is when we: 1. Use -fno-semantic-interposition. As Fangrui notes: ``` Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. ``` This causes references to jiffies to refer to `.Ljiffies$local` when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to `.Ljiffies_64$local` in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. Combined with ... 2. Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to `jiffies_64` anywhere to replace with `jiffies`. And thus `.Ljiffies$local` and `.Ljiffies_64$local` no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, we observe spooky bugs where the kernel appeared to boot, but init doesn't get scheduled. Instead, we can avoid the ODR violation by matching other arch's by defining jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Link: ClangBuiltLinux/linux#852 Fixes: 40747ff ("asmlinkage: Make jiffies visible") Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Suggested-by: Fangrui Song <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Signed-off-by: Bob Haarman <[email protected]> (am from https://lore.kernel.org/lkml/[email protected]/T/#u) Bug: 155426344 Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: I6a5d3aeac388a0bc8254b83fa92e12376a04f922

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: John Vincent <[email protected]> Signed-off-by: John Vincent <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Lee Jones <[email protected]> Change-Id: I7bb7ab4820306d99fa2ebacbfbd6ef397bb43dc3

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

`jiffies` and `jiffies_64` are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all arch's in: include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c for all arch's. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via `jiffies_64 = jiffies;`. As Fangrui notes: ``` In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. ``` So we have an ODR violation (UB), which we seem to have gotten away with thus far. Where it becomes harmful is when we: 1. Use -fno-semantic-interposition. As Fangrui notes: ``` Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. ``` This causes references to jiffies to refer to `.Ljiffies$local` when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to `.Ljiffies_64$local` in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. Combined with ... 2. Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to `jiffies_64` anywhere to replace with `jiffies`. And thus `.Ljiffies$local` and `.Ljiffies_64$local` no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, we observe spooky bugs where the kernel appeared to boot, but init doesn't get scheduled. Instead, we can avoid the ODR violation by matching other arch's by defining jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Link: ClangBuiltLinux/linux#852 Fixes: 40747ff ("asmlinkage: Make jiffies visible") Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Suggested-by: Fangrui Song <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Signed-off-by: Bob Haarman <[email protected]> (am from https://lore.kernel.org/lkml/[email protected]/T/#u) Bug: 155426344 Signed-off-by: Nick Desaulniers <[email protected]> Change-Id: I6a5d3aeac388a0bc8254b83fa92e12376a04f922

commit d8ad6d39c35d2b44b3d48b787df7f3359381dcbf upstream. 'jiffies' and 'jiffies_64' are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via a linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all architectures in include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via the linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via 'jiffies_64 = jiffies;'. As Fangrui notes: In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. This results in an ODR violation (UB), which seems to have survived thus far. Where it becomes harmful is when; 1. -fno-semantic-interposition is used: As Fangrui notes: Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. This causes references to jiffies to refer to '.Ljiffies$local' when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to '.Ljiffies_64$local' in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. 2. Full LTO Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to jiffies_64' anywhere to replace with 'jiffies'. And thus '.Ljiffies$local' and '.Ljiffies_64$local' no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, spooky bugs have been observed where the kernel appeared to boot, but init doesn't get scheduled. Avoid the ODR violation by matching other architectures and define jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Fixes: 40747ff ("asmlinkage: Make jiffies visible") Reported-by: Nathan Chancellor <[email protected]> Reported-by: Alistair Delva <[email protected]> Debugged-by: Nick Desaulniers <[email protected]> Debugged-by: Sami Tolvanen <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Bob Haarman <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Sedat Dilek <[email protected]> # build+boot on Reviewed-by: Andi Kleen <[email protected]> Reviewed-by: Josh Poimboeuf <[email protected]> Cc: [email protected] Link: ClangBuiltLinux/linux#852 Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

nathanchance added [BUG] Untriaged Something isn't working [FEATURE] LTO Related to building the kernel with LLVM Link Time Optimization labels Feb 2, 2020

nathanchance mentioned this issue Feb 12, 2020

objtool failures starting with next-20200212 #872

Closed

nathanchance added a commit to nathanchance/WSL2-Linux-Kernel that referenced this issue Feb 14, 2020

Microsoft/config-wsl: Disable LTO

4d47c2a

Currently broken with clang-11 :( Link: ClangBuiltLinux/linux#852 Signed-off-by: Nathan Chancellor <[email protected]>

nickdesaulniers self-assigned this May 6, 2020

nickdesaulniers mentioned this issue May 7, 2020

disable KASLR when using GDB ClangBuiltLinux/boot-utils#15

Merged

nickdesaulniers added [PATCH] Exists There is a patch that fixes this issue [BUG] linux A bug that should be fixed in the mainline kernel. and removed [BUG] Untriaged Something isn't working labels May 13, 2020

nickdesaulniers added [PATCH] Submitted A patch has been submitted for review and removed [PATCH] Exists There is a patch that fixes this issue labels May 15, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

android-4.19 Cuttlefish x86 does not boot after LLVM commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74 #852

android-4.19 Cuttlefish x86 does not boot after LLVM commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74 #852

nathanchance commented Feb 2, 2020

MaskRay commented Feb 2, 2020

Uh oh!

nickdesaulniers commented Feb 2, 2020

Uh oh!

nathanchance commented Feb 2, 2020

Uh oh!

nathanchance commented Feb 3, 2020 •

edited

Loading

Uh oh!

MaskRay commented Feb 3, 2020 •

edited

Loading

Uh oh!

nathanchance commented Feb 3, 2020

Uh oh!

nathanchance commented Feb 3, 2020

Uh oh!

nickdesaulniers commented May 5, 2020

Uh oh!

nickdesaulniers commented May 9, 2020

Uh oh!

nickdesaulniers commented May 12, 2020

Uh oh!

nickdesaulniers commented May 13, 2020

Uh oh!

nickdesaulniers commented May 13, 2020

Uh oh!

nathanchance commented May 15, 2020

Uh oh!

nickdesaulniers commented May 15, 2020

Uh oh!

android-4.19 Cuttlefish x86 does not boot after LLVM commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74 #852

android-4.19 Cuttlefish x86 does not boot after LLVM commit 5b22bcc2b70d82c73ce5428170dcc2038a729d74 #852

Comments

nathanchance commented Feb 2, 2020

MaskRay commented Feb 2, 2020

Uh oh!

nickdesaulniers commented Feb 2, 2020

Uh oh!

nathanchance commented Feb 2, 2020

Uh oh!

nathanchance commented Feb 3, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaskRay commented Feb 3, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nathanchance commented Feb 3, 2020

Uh oh!

nathanchance commented Feb 3, 2020

Uh oh!

nickdesaulniers commented May 5, 2020

Uh oh!

nickdesaulniers commented May 9, 2020

Uh oh!

nickdesaulniers commented May 12, 2020

Uh oh!

nickdesaulniers commented May 13, 2020

Uh oh!

nickdesaulniers commented May 13, 2020

Uh oh!

nathanchance commented May 15, 2020

Uh oh!

nickdesaulniers commented May 15, 2020

Uh oh!

nathanchance commented Feb 3, 2020 •

edited

Loading

MaskRay commented Feb 3, 2020 •

edited

Loading