wont boot on N976x #213
Open
wont boot on N976x #213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…char * Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
… check Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…ress clang warning Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…suppress the warning Signed-off-by: Denis Efremov <[email protected]>
…sscanf format Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…e() result Signed-off-by: Denis Efremov <[email protected]>
…ation warning Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
A recent LLVM 11 commit [1] made LLD stop implicitly coalescing some
temporary LLVM sections, namely .{data,bss}..compoundliteral.XXX:
[30] .data..compoundli PROGBITS ffffffff9ac9a000 19e9a000
000000000000cea0 0000000000000000 WA 0 0 32
[31] .rela.data..compo RELA 0000000000000000 40965440
0000000000001d88 0000000000000018 I 2238 30 8
[32] .data..compoundli PROGBITS ffffffff9aca6ea0 19ea6ea0
00000000000033c0 0000000000000000 WA 0 0 32
[33] .rela.data..compo RELA 0000000000000000 409671c8
0000000000000948 0000000000000018 I 2238 32 8
[...]
[2213] .bss..compoundlit NOBITS ffffffffa3000000 1d85c000
00000000000000a0 0000000000000000 WA 0 0 32
[2214] .bss..compoundlit NOBITS ffffffffa30000a0 1d85c000
0000000000000040 0000000000000000 WA 0 0 32
[...]
.{data,bss}..L<symbol name> sections are also created in some cases.
While there aren't any in this example, they should also be coalesced to
be safe in case some config or future LLVM change makes it start
creating more of those sections in the future. For example, enabling
global merging causes ..L_MergedGlobals sections to be created, but it's
likely that other changes will result in such sections as well.
While these extra sections don't typically cause any breakage, they do
inflate the vmlinux size due to the overhead of storing metadata for
thousands of extra sections.
It's also worth noting that for some reason, some downstream Android
kernels can't boot at all if these sections aren't coalesced.
This issue isn't limited to any specific architecture; it affects arm64
and x86 if CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is forced on.
Example on x86 allyesconfig:
Before: 2241 sections, 1171169 KiB
After: 56 sections, 1170972 KiB
[1] llvm/llvm-project@9e33c09
Suggested-by: Fangrui Song <[email protected]>
Signed-off-by: Danny Lin <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Cc: [email protected] # v4.4+
Link: ClangBuiltLinux/linux#958
cuttlefish_defconfig explicitly enables options that fail to compile with compilers other than clang. This change detects when a different compiler is used and disables clang-specific features after printing a warning. Bug: 145297810 Change-Id: I3371576b45c9715a63c5668ab58e996cab612f53 Signed-off-by: Sami Tolvanen <[email protected]>
This adds support for compiling the kernel with optimizations offered by LLVM's polyhedral loop optimizer known as Polly, which can improve performance by improving cache locality in loops. Note that LLVM is not compiled with Polly by default -- it must be enabled explicitly. Signed-off-by: Danny Lin <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Will Deacon <[email protected]> Change-Id: I8a14d6dd51d46b6942e68720e24217d1564b7869 [nd: conflicts due to ANDROID patches for LTO and SCS] (cherry picked from commit 691efbedc60d2a7364a90e38882fc762f06f52c4) Bug: 153418016 Bug: 157279372 Signed-off-by: Nick Desaulniers <[email protected]> (cherry picked from commit 64ea9b4b072b37bd624dd98b963161fd22c1be34)
Commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to
link VDSO") switched to using LD explicitly. The --build-id option
needs to be passed explicitly, similar to x86. Add this option.
Fixes: 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
Reviewed-by: Masahiro Yamada <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
[will: drop redundant use of 'call ld-option' as requested by Masahiro]
Signed-off-by: Will Deacon <[email protected]>
Change-Id: I4a0f5c1bb60bda682221a7ff96a783bf8731cc00
[nd: conflict due to ANDROID LTO and CFI]
(cherry picked from commit 7a0a93c51799edc45ee57c6cc1679aa94f1e03d5)
Bug: 153418016
Bug: 157279372
Signed-off-by: Nick Desaulniers <[email protected]>
(cherry picked from commit a9ee8bba814d956404c12b1c2e2c24cf4b710f08)
ld.lld distributed in clang-r353983c AOSP LLVM release (the final AOSP LLVM release for Android Q) did not support `-n` linker flag. It was eventually added to clang-r360593. Android OEM's may wish to still use ld.lld to link their kernels for Q. This flag was disabled for Pixel 4 in go/pag/1258086. This patch is equivalent, but rebased on upstream changes that removed cc-ldoption in favor of ld-option. For Android R, the final AOSP LLVM release, clang-r383902 has long supported `-n` for ld.lld. Change-Id: Iab41c9e1039e163113b428fc487a4a0708822faa Bug: 63740206 Bug: 157279372 Link: ClangBuiltLinux/linux#340 Link: https://bugs.llvm.org/show_bug.cgi?id=40542 Signed-off-by: Nick Desaulniers <[email protected]>
Change VM_MAX_READAHEAD value from the default 128KB to a configurable value. This will allow the readahead window to grow to a maximum size bigger than 128KB during boot, which could benefit to sequential read throughput and thus boot performance. Signed-off-by: Wei Wang <[email protected]>
With CONFIG_THINLTO and CFI both enabled, LLVM appends a hash to the names of all static functions. This breaks userspace tools, so strip out the hash from output. Bug: 147422318 Change-Id: Ibea6be089d530e92dcd191481cb02549041203f6 Signed-off-by: Sami Tolvanen <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
A trace point string cannot be const because the underlying special section is not marked const. An LTO build complains about the section attribute mismatch. Fix it by not marking the trace point string in afs const. Cc: [email protected] Signed-off-by: Andi Kleen <[email protected]>
…disabled Otherwise LTO will inline them anyways and cause a large kernel text increase. Since the explicit intention here is to not inline them marking them noinline is good documentation even for the non LTO case. Signed-off-by: Andi Kleen <[email protected]>
The single caller passes a string to delta_ipc_open, which copies with a
fixed size larger than the string. So it copies some random data after
the original string the ro segment.
If the string was at the end of a page it may fault.
Just copy the string with a normal strcpy after clearing the field.
Found by a LTO build (which errors out)
because the compiler inlines the functions and can resolve
the string sizes and triggers the compile time checks in memcpy.
In function ‘memcpy’,
inlined from ‘delta_ipc_open.constprop’ at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0,
inlined from ‘delta_mjpeg_ipc_open’ at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0,
inlined from ‘delta_mjpeg_decode’ at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0:
/home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to ‘__read_overflow2’ declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
gcc 5 has a new no_reorder attribute that prevents top level reordering only for that symbol. Kernels don't like any reordering of initcalls between files, as several initcalls depend on each other. LTO previously needed to use -fno-toplevel-reordering to prevent boot failures. Add a __noreorder wrapper for the no_reorder attribute and use it for initcalls. Signed-off-by: Andi Kleen <[email protected]>
Disable LTO for the BPF interpreter. This works around a gcc bug in the LTO partitioner that partitions the jumptable used the BPF interpreter into a different LTO unit. This in term causes assembler errors because the jump table contains references to the code labels in the original file. gcc problem tracked in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 Signed-off-by: Andi Kleen <[email protected]>
Building the kernel with an LTO-enabled GCC spits out the following "const"
warning for the cpu_ops code:
mm/percpu.c:2168:20: error: pcpu_fc_names causes a section type conflict
with dt_supported_cpu_ops
const char * const pcpu_fc_names[PCPU_FC_NR] __initconst = {
^
arch/arm64/kernel/cpu_ops.c:34:37: note: ‘dt_supported_cpu_ops’ was declared here
static const struct cpu_operations *dt_supported_cpu_ops[] __initconst = {
Fix it by adding missed const qualifiers.
Signed-off-by: Yury Norov <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Based on Andi Kleen <[email protected]> work. Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
|
same issue, on a s10e SM-G970F edit: fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
just to know why wont boot on HVJ5