wont boot on N976x #213

Signed-off-by: Denis Efremov <[email protected]>

…char * 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]>

…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]>

…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]>

Move dev_info() out of switch. Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

[efremov: change permissions from 0755 to 0644] Signed-off-by: djb77 <[email protected]> Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Userspace parses this and sets the ro.boot.verifiedbootstate prop according to the value that this flag has. When ro.boot.verifiedbootstate is not 'green', SafetyNet is tripped and fails the CTS test. Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check. SafetyNet checks androidboot.veritymode in Nougat, so remove it. Additionally, remove androidboot.enable_dm_verity and androidboot.secboot in case SafetyNet will check them in the future. Signed-off-by: Sultanxda <[email protected]> Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Run `su` to get root. HELLO NAÏVE TECH JOURNALISTS: This commit here introduces a driver used during development, because having access to scary debugging facilities is useful during kernel development. This driver is disabled by default, and when it is enabled, it spews warnings all over the place to encourage people who turn it on by accident to turn it off. It's exceedingly unlikely that somebody turns this on without intending to do so. You really have to fish around and make a concerted effort to get it enabled and working, and the warning messages it gives during the build and boot processes are really an eyesore. So, if you've found this commit because some idiot shipped a kernel to their users, you have every reason to blame that idiot, and not this commit. And if the fool insists it was an 'accident', he's not telling the truth. This is from: https://git.zx2c4.com/kernel-assisted-superuser/about Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Default fallback scheduler for ondemand and conservative schedulers is performance one. This commit makes schedutil the default fallback scheduler. Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Change-Id: Id57abf0a4bd0b433fecc622eecb383cd4ea29d17 Signed-off-by: Paul Keith <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Based on ideas of FranciscoFranco's non-generic driver. Sysfs node: /sys/class/misc/boeffla_wakelock_blocker/wakelock_blocker - list of wakelocks to be blocked, separated by semicolons /sys/class/misc/boeffla_wakelock_blocker/debug - write: 0/1 to switch off and on debug logging into dmesg - read: get current driver internals /sys/class/misc/boeffla_wakelock_blocker/version - show driver version Signed-off-by: andip71 <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Use only read permissions for version_show. Signed-off-by: Denis Efremov <[email protected]>

It's not used. Type conversion size_t > int is not needed. Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

The previous 255 limit seemed to be not enough to hold all the Samsung stock defined wakelocks that look safe to block.

Seems blocking them does not affect device stability.

Signed-off-by: Denis Efremov <[email protected]>

Added Moro Sound Module Signed-off-by: Nico Becker <[email protected]> Signed-off-by: Denis Efremov <[email protected]>

Remove first variable, because it's not used in fmt string. Swap get_headphone_gain_l(), headphone_gain_l, get_headphone_gain_r(), headphone_gain_r according to the fmt string. Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

This driver, based on Sultanxda's input boost driver, boosts all available cpus to max freq after recieving an input notification from the fingerprint sensor to reduce lag. Signed-off-by: Joe Maples <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

@HRTKernel

Thanks, @HRTKernel! Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Since "sched/fair: Align PELT windows between cfs_rq and its se" the upstream kernel has initialised the whole content of sched_avg to zero on fork. When util_est was backported, we missed this and so ended up with util_est values copied from the parent task. Add the zero initialisation which is present upstream and ensure that util_est values always start from a known point. Fixes: 700f117 ("BACKPORT: sched/fair: Add util_est on top of PELT") Reported-by: Puja Gupta <[email protected]> Cc: Dietmar Eggemann <[email protected]> Cc: Abhijeet Dharmapurikar <[email protected]> Cc: Patrick Bellasi <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Saravana Kannan <[email protected]> Change-Id: I06995e4320d606a52761d0e773baf28fcd1e2680 Signed-off-by: Chris Redpath <[email protected]> Signed-off-by: celtare21 <[email protected]> (cherry picked from commit a4af8d41cb4acf9c689f27e4afc81692520eb1bb) (cherry picked from commit e701e0d73c2917ed34951b7f509cdb40c795e38d)

Blindly ignoring frequency updates because of work_in_progress can leave the CPUs at the wrong frequency for a long time. It's better to update the frequency immediately than wait for a future event that might take a long time to come. The irq_work code already ignores double queuing of work. So, that part of the code is still safe when the work_in_progress flag is ignored. Change-Id: Id0b3711314dfbfa18b5f4bce30a239ee3cf962d6 Signed-off-by: Vikram Mulukutla <[email protected]> Signed-off-by: Saravana Kannan <[email protected]> (cherry picked from commit 5dec9a7e188d43d9639e4c3e3315f0047f83d96a) (cherry picked from commit 33628fe3cd7c3d9590113901647655478e822927)

Signed-off-by: Denis Efremov <[email protected]>

The arm64 uapi sigcontext.h can be included by 32-bit userspace modules. Since arm and arm64 sigcontext definition are not compatible, add arm sigcontext definition to arm64 sigcontext.h. Change-Id: I94109b094f6c8376fdaeb2822d7b26d18ddfb2bc Signed-off-by: David Ng <[email protected]> Signed-off-by: Ameya Thakur <[email protected]> Signed-off-by: Prasad Sodagudi <[email protected]>

Signed-Off-by: Andreas Schneider <[email protected]>

Signed-off-by: Andreas Schneider <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: djb77 <[email protected]>

Other drivers like the mtp driver use a proper 'function.name' to make the configfs work. So lets correct mass storages name which will allow drivedroid to work.

__mark_inode_dirty already takes care of that, and for the XFS lazytime implementation we need to know that ->dirty_inode was called because I_DIRTY_TIME was set. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Signed-off-by: Darrick J. Wong <[email protected]>

When using GCC as compiler and LLVM's lld as linker, linking setup.elf fails: LD arch/x86/boot/setup.elf ld.lld: error: init sections too big! This happens because GCC generates .eh_frame sections for most of the files in that directory, then ld.lld places the merged section before __end_init, triggering an assert in the linker script. Fix this by discarding the .eh_frame sections, as suggested by Boris. The kernel proper linker script discards them too. [ bp: Going back in history, 64-bit kernel proper has been discarding .eh_frame since 2002: commit acca80acefe20420e69561cf55be64f16c34ea97 Author: Andi Kleen <[email protected]> Date: Tue Oct 29 23:54:35 2002 -0800 [PATCH] x86-64 updates for 2.5.44 ... - Remove the .eh_frame on linking. This saves several hundred KB in the bzImage ] Suggested-by: Borislav Petkov <[email protected]> Signed-off-by: Ilie Halip <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Nick Desaulniers <[email protected] Cc: Andy Lutomirski <[email protected]> Cc: [email protected] Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: x86-ml <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Link: ClangBuiltLinux/linux#760 Link: https://lkml.kernel.org/r/[email protected]

Currently LDFLAGS is not cleared, so same flags are accumulated in LDFLAGS when the top Makefile is recursively invoked. I found unneeded rebuild for ARCH=arm64 when CONFIG_TRIM_UNUSED_KSYMS is enabled. If include/generated/autoksyms.h is updated, the top Makefile is recursively invoked, then arch/arm64/Makefile adds one more '-maarch64linux'. Due to the command line change, modules are rebuilt needlessly. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Nicolas Pitre <[email protected]>

Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched various false positives: - commit e74fc97 ("Turn off -Wmaybe-uninitialized when building with -Os") turned off this option for -Os. - commit 815eb71 ("Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for CONFIG_PROFILE_ALL_BRANCHES - commit a76bcf5 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"") turned off this option for GCC < 4.9 Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903 I think this looks better by shifting the logic from Makefile to Kconfig. Link: ClangBuiltLinux/linux#350 Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nick Desaulniers <[email protected]>

The clang option -Oz enables *aggressive* optimization for size, which doesn't necessarily result in smaller images, but can have negative impact on performance. Switch back to the less aggressive -Os. This reverts commit 6748cb3. Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

arch/arc/Makefile overrides -O2 with -O3. This is the only user of ARCH_CFLAGS. There is no user of ARCH_CPPFLAGS or ARCH_AFLAGS. My plan is to remove ARCH_{CPP,A,C}FLAGS after refactoring the ARC Makefile. Currently, ARC has no way to enable -Wmaybe-uninitialized because both -O3 and -Os disable it. Enabling it will be useful for compile-testing. This commit allows allmodconfig (, which defaults to -O2) to enable it. Add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3=y to all the defconfig files in arch/arc/configs/ in order to keep the current config settings. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Vineet Gupta <[email protected]>

We have some rather random rules about when we accept the "maybe-initialized" warnings, and when we don't. For example, we consider it unreliable for gcc versions < 4.9, but also if -O3 is enabled, or if optimizing for size. And then various kernel config options disabled it, because they know that they trigger that warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES). And now gcc-10 seems to be introducing a lot of those warnings too, so it falls under the same heading as 4.9 did. At the same time, we have a very straightforward way to _enable_ that warning when wanted: use "W=2" to enable more warnings. So stop playing these ad-hoc games, and just disable that warning by default, with the known and straight-forward "if you want to work on the extra compiler warnings, use W=123". Would it be great to have code that is always so obvious that it never confuses the compiler whether a variable is used initialized or not? Yes, it would. In a perfect world, the compilers would be smarter, and our source code would be simpler. That's currently not the world we live in, though. Signed-off-by: Linus Torvalds <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

gcc 10 will default to -fno-common, which causes this error at link time: (.text+0x0): multiple definition of `yylloc'; dtc-lexer.lex.o (symbol from plugin):(.text+0x0): first defined here This is because both dtc-lexer as well as dtc-parser define the same global symbol yyloc. Before with -fcommon those were merged into one defintion. The proper solution would be to to mark this as "extern", however that leads to: dtc-lexer.l:26:16: error: redundant redeclaration of 'yylloc' [-Werror=redundant-decls] 26 | extern YYLTYPE yylloc; | ^~~~~~ In file included from dtc-lexer.l:24: dtc-parser.tab.h:127:16: note: previous declaration of 'yylloc' was here 127 | extern YYLTYPE yylloc; | ^~~~~~ cc1: all warnings being treated as errors which means the declaration is completely redundant and can just be dropped. Signed-off-by: Dirk Mueller <[email protected]> Signed-off-by: David Gibson <[email protected]> [robh: cherry-pick from upstream] Cc: [email protected] Signed-off-by: Rob Herring <[email protected]> [evdenis: scripts/dtc/dtc-parser.tab.c_shipped fixed] Signed-off-by: Denis Efremov <[email protected]>

The issue described here: https://darvincitech.wordpress.com/2019/11/04/detecting-magisk-hide/ Signed-off-by: Denis Efremov <[email protected]>

commit 6f303d60534c46aa1a239f29c321f95c83dda748 upstream. We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit c0d9782f5b6d7157635ae2fd782a4b27d55a6013 upstream. From the GCC manual: copy copy(function) The copy attribute applies the set of attributes with which function has been declared to the declaration of the function to which the attribute is applied. The attribute is designed for libraries that define aliases or function resolvers that are expected to specify the same set of attributes as their targets. The copy attribute can be used with functions, variables, or types. However, the kind of symbol to which the attribute is applied (either function or variable) must match the kind of symbol to which the argument refers. The copy attribute copies only syntactic and semantic attributes but not attributes that affect a symbol’s linkage or visibility such as alias, visibility, or weak. The deprecated attribute is also not copied. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html The upcoming GCC 9 release extends the -Wmissing-attributes warnings (enabled by -Wall) to C and aliases: it warns when particular function attributes are missing in the aliases but not in their target, e.g.: void __cold f(void) {} void __alias("f") g(void); diagnoses: warning: 'g' specifies less restrictive attribute than its target 'f': 'cold' [-Wmissing-attributes] Using __copy(f) we can copy the __cold attribute from f to g: void __cold f(void) {} void __copy(f) __alias("f") g(void); This attribute is most useful to deal with situations where an alias is declared but we don't know the exact attributes the target has. For instance, in the kernel, the widely used module_init/exit macros define the init/cleanup_module aliases, but those cannot be marked always as __init/__exit since some modules do not have their functions marked as such. Suggested-by: Martin Sebor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Stefan Agner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit a6e60d84989fa0e91db7f236eda40453b0e44afa upstream. The upcoming GCC 9 release extends the -Wmissing-attributes warnings (enabled by -Wall) to C and aliases: it warns when particular function attributes are missing in the aliases but not in their target. In particular, it triggers for all the init/cleanup_module aliases in the kernel (defined by the module_init/exit macros), ending up being very noisy. These aliases point to the __init/__exit functions of a module, which are defined as __cold (among other attributes). However, the aliases themselves do not have the __cold attribute. Since the compiler behaves differently when compiling a __cold function as well as when compiling paths leading to calls to __cold functions, the warning is trying to point out the possibly-forgotten attribute in the alias. In order to keep the warning enabled, we decided to silence this case. Ideally, we would mark the aliases directly as __init/__exit. However, there are currently around 132 modules in the kernel which are missing __init/__exit in their init/cleanup functions (either because they are missing, or for other reasons, e.g. the functions being called from somewhere else); and a section mismatch is a hard error. A conservative alternative was to mark the aliases as __cold only. However, since we would like to eventually enforce __init/__exit to be always marked, we chose to use the new __copy function attribute (introduced by GCC 9 as well to deal with this). With it, we copy the attributes used by the target functions into the aliases. This way, functions that were not marked as __init/__exit won't have their aliases marked either, and therefore there won't be a section mismatch. Note that the warning would go away marking either the extern declaration, the definition, or both. However, we only mark the definition of the alias, since we do not want callers (which only see the declaration) to be compiled as if the function was __cold (and therefore the paths leading to those calls would be assumed to be unlikely). Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Martin Sebor <[email protected]> Acked-by: Jessica Yu <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Stefan Agner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ] In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is a GCC only option so clang rightfully complains: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option However, by default, this is merely a warning so the build happily goes on with a slew of these warnings in the process. Commit c3f0d0b ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang") worked around this behavior in cc-option by adding -Werror so that unknown flags cause an error. However, this all happens silently and when an unknown flag is added to the build unconditionally like -Wno-psabi, cc-option will always fail because there is always an unknown flag in the list of flags. This manifested as link time failures in the arm64 libstub because -fno-stack-protector didn't get added to KBUILD_CFLAGS. To avoid these weird cryptic failures in the future, make clang behave like gcc and immediately error when it encounters an unknown flag by adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added unconditionally for clang because it is supported by at least 3.0.0, according to godbolt [1] and 4.0.0, according to its documentation [2], which is far earlier than we typically support. [1]: https://godbolt.org/z/7F7rm3 [2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option Link: ClangBuiltLinux/linux#511 Link: ClangBuiltLinux/linux#517 Suggested-by: Peter Smith <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream. CLANG_FLAGS is initialized by the following line: CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) ..., which is run only when CROSS_COMPILE is set. Some build targets (bindeb-pkg etc.) recurse to the top Makefile. When you build the kernel with Clang but without CROSS_COMPILE, the same compiler flags such as -no-integrated-as are accumulated into CLANG_FLAGS. If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg', Kbuild will recompile everything needlessly due to the build command change. Fix this by correctly initializing CLANG_FLAGS. Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") Cc: <[email protected]> # v5.0+ Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit a73619a845d5625079cc1b3b820f44c899618388 ] The __FILE__ macro is used everywhere in the kernel to locate the file printing the log message, such as WARN_ON(), etc. If the kernel is built out of tree, this can be a long absolute path, like this: WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:... This is because Kbuild runs in the objtree instead of the srctree, then __FILE__ is expanded to a file path prefixed with $(srctree)/. Commit 9da0763 ("kbuild: Use relative path when building in a subdir of the source tree") improved this to some extent; $(srctree) becomes ".." if the objtree is a child of the srctree. For other cases of out-of-tree build, __FILE__ is still the absolute path. It also means the kernel image depends on where it was built. A brand-new option from GCC, -fmacro-prefix-map, solves this problem. If your compiler supports it, __FILE__ is the relative path from the srctree regardless of O= option. This provides more readable log and more reproducible builds. Please note __FILE__ is always an absolute path for external modules. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 29be86d7f9cb18df4123f309ac7857570513e8bc ] The gcc -fcf-protection=branch option is not compatible with -mindirect-branch=thunk-extern. The latter is used when CONFIG_RETPOLINE is selected, and this will fail to build with a gcc which has -fcf-protection=branch enabled by default. Adding -fcf-protection=none when building with retpoline enabled prevents such build failures. Signed-off-by: Seth Forshee <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit e07db28eea38ed4e332b3a89f3995c86b713cb5b ] Building a single target in an external module fails due to missing .tmp_versions directory. For example, $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o will fail in the following way: CC [M] /home/masahiro/foo/foo.o /bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent This is because $(cmd_crmodverdir) is executed only before building /, %/, %.ko single targets of external modules. Create .tmp_versions in the 'prepare' target. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit e00d8880481497474792d28c14479a9fb6752046 ] Commit c3ff2a5193fa ("powerpc/32: add stack protector support") caused kernel panic on PowerPC when an external module is used with CONFIG_STACKPROTECTOR because the 'prepare' target was not executed for the external module build. Commit e07db28eea38 ("kbuild: fix single target build for external module") turned it into a build error because the 'prepare' target is now executed but the 'prepare0' target is missing for the external module build. External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is also broken in the same way. Move 'PHONY += prepare0' to the common place. GNU Make is fine with missing rule for phony targets. I also removed the comment which is wrong irrespective of this commit. I minimize the change so it can be easily backported to 4.20.x To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target build for external module"), and then this commit. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891 Fixes: e07db28eea38 ("kbuild: fix single target build for external module") Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support") Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries") Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries") Cc: linux-stable <[email protected]> # v4.20 Reported-by: Samuel Holland <[email protected]> Reported-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Tested-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

commit 5c45de21a2223fe46cf9488c99a7fbcf01527670 upstream. This is a fine warning, but we still have a number of zero-length arrays in the kernel that come from the traditional gcc extension. Yes, they are getting converted to flexible arrays, but in the meantime the gcc-10 warning about zero-length bounds is very verbose, and is hiding other issues. I missed one actual build failure because it was hidden among hundreds of lines of warning. Thankfully I caught it on the second go before pushing things out, but it convinced me that I really need to disable the new warnings for now. We'll hopefully be all done with our conversion to flexible arrays in the not too distant future, and we can then re-enable this warning. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 44720996e2d79e47d508b0abe99b931a726a3197 upstream. This is another fine warning, related to the 'zero-length-bounds' one, but hitting the same historical code in the kernel. Because C didn't historically support flexible array members, we have code that instead uses a one-sized array, the same way we have cases of zero-sized arrays. The one-sized arrays come from either not wanting to use the gcc zero-sized array extension, or from a slight convenience-feature, where particularly for strings, the size of the structure now includes the allocation for the final NUL character. So with a "char name[1];" at the end of a structure, you can do things like v = my_malloc(sizeof(struct vendor) + strlen(name)); and avoid the "+1" for the terminator. Yes, the modern way to do that is with a flexible array, and using 'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That also technically gets the size "more correct" in that it avoids any alignment (and thus padding) issues, but this is another long-term cleanup thing that will not happen for 5.7. So disable the warning for now, even though it's potentially quite useful. Having a slew of warnings that then hide more urgent new issues is not an improvement. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 5a76021c2eff7fcf2f0918a08fd8a37ce7922921 upstream. This is the final array bounds warning removal for gcc-10 for now. Again, the warning is good, and we should re-enable all these warnings when we have converted all the legacy array declaration cases to flexible arrays. But in the meantime, it's just noise. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit adc71920969870dfa54e8f40dac8616284832d02 upstream. gcc-10 now warns about passing aliasing pointers to functions that take restricted pointers. That's actually a great warning, and if we ever start using 'restrict' in the kernel, it might be quite useful. But right now we don't, and it turns out that the only thing this warns about is an idiom where we have declared a few functions to be "printf-like" (which seems to make gcc pick up the restricted pointer thing), and then we print to the same buffer that we also use as an input. And people do that as an odd concatenation pattern, with code like this: #define sysfs_show_gen_prop(buffer, fmt, ...) \ snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__) where we have 'buffer' as both the destination of the final result, and as the initial argument. Yes, it's a bit questionable. And outside of the kernel, people do have standard declarations like int snprintf( char *restrict buffer, size_t bufsz, const char *restrict format, ... ); where that output buffer is marked as a restrict pointer that cannot alias with any other arguments. But in the context of the kernel, that 'use snprintf() to concatenate to the end result' does work, and the pattern shows up in multiple places. And we have not marked our own version of snprintf() as taking restrict pointers, so the warning is incorrect for now, and gcc picks it up on its own. If we do start using 'restrict' in the kernel (and it might be a good idea if people find places where it matters), we'll need to figure out how to avoid this issue for snprintf and friends. But in the meantime, this warning is not useful. Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit b1112139a103b4b1101d0d2d72931f2d33d8c978 upstream. gcc-10 will rename --param=allow-store-data-races=0 to -fno-allow-store-data-races. The flag change happened at https://gcc.gnu.org/PR92046. Signed-off-by: Sergei Trofimovich <[email protected]> Acked-by: Jiri Kosina <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Cc: Thomas Backlund <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit f4d74ef6220c1eda0875da30457bef5c7111ab06 ] If seq_file .next function does not change position index, read after some lseek can generate unexpected output. https://bugzilla.kernel.org/show_bug.cgi?id=206283 Signed-off-by: Vasily Averin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Acked-by: Peter Oberparleiter <[email protected]> Cc: Al Viro <[email protected]> Cc: Davidlohr Bueso <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Manfred Spraul <[email protected]> Cc: NeilBrown <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Waiman Long <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit cfc905f158eaa099d6258031614d11869e7ef71c ] GCOV built with GCC 10 doesn't initialize n_function variable. This produces different kernel panics as was seen by Colin in Ubuntu and me in FC 32. As a workaround, let's disable GCOV build for broken GCC 10 version. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1891288 Link: https://lore.kernel.org/lkml/[email protected] Link: https://lore.kernel.org/lkml/CAHk-=whbijeSdSvx-Xcr0DPMj0BiwhJ+uiNnDSVZcr_h_kg7UA@mail.gmail.com/ Cc: Colin Ian King <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 40249c6962075c040fd071339acae524f18bfac9 ] Using gcov to collect coverage data for kernels compiled with GCC 10.1 causes random malfunctions and kernel crashes. This is the result of a changed GCOV_COUNTERS value in GCC 10.1 that causes a mismatch between the layout of the gcov_info structure created by GCC profiling code and the related structure used by the kernel. Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable config GCOV_KERNEL for use with GCC 10. Reported-by: Colin Ian King <[email protected]> Reported-by: Leon Romanovsky <[email protected]> Signed-off-by: Peter Oberparleiter <[email protected]> Tested-by: Leon Romanovsky <[email protected]> Tested-and-Acked-by: Colin Ian King <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

commit 4b50c8c4eaf06a825d1c005c0b1b4a8307087b83 upstream. This code does not work as stated in the comment. $(CONFIG_MODVERSIONS) is always empty because it is expanded before include/config/auto.conf is included. Hence, 'make modules' with CONFIG_MODVERSION=y cannot record the version CRCs. This has been broken since 2003, commit ("kbuild: Enable modules to be build using the "make dir/" syntax"). [1] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7 Cc: linux-stable <[email protected]> # v2.5.71+ Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream. When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since llvm/llvm-project@3452a0d) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: [email protected] Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Fangrui Song <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Link: ClangBuiltLinux/linux#1099 Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

There are some people interested in experimenting with Clang's integrated assembler. To make it easy to do so without source modification, allow the user to specify 'AS=clang' as part of the make command to avoid adding '-no-integrated-as' to the {A,C}FLAGS. Link: ClangBuiltLinux/linux#577 Suggested-by: Dmitry Golovin <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

This is no longer a valid option in clang, it was removed in 3.5, which we don't support. llvm/llvm-project@cb3f812 Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

It may be useful to compile host programs with different flags (e.g. hardening). Ensure that objtool picks up the appropriate flags. Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/r/05a360681176f1423cb2fde8faae3a0a0261afc5.1523560825.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>

Commit 0c3b7e4 ("tools build: Add support for host programs format") introduced host_c_flags which referenced CHOSTFLAGS. The actual name of the variable is HOSTCFLAGS. Fix this up. Fixes: 0c3b7e4 ("tools build: Add support for host programs format") Signed-off-by: Laura Abbott <[email protected]> Acked-by: Jiri Olsa <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from documents") noted, we rarely use $(AS) directly in the kernel build. Now that the only/last user of $(AS) in drivers/net/wan/Makefile was converted to $(CC), $(AS) is no longer used in the build process. You can still pass in AS=clang, which is just a switch to turn on the LLVM integrated assembler. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]>

The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>

Currently, this Makefile hardcodes GNU ar, meaning that if it is not available, there is no way to supply a different one and the build will fail. $ make AR=llvm-ar CC=clang LD=ld.lld HOSTAR=llvm-ar HOSTCC=clang \ HOSTLD=ld.lld HOSTLDFLAGS=-fuse-ld=lld defconfig modules_prepare ... AR /out/tools/objtool/libsubcmd.a /bin/sh: 1: ar: not found ... Follow the logic of HOST{CC,LD} and allow the user to specify a different ar tool via HOSTAR (which is used elsewhere in other tools/ Makefiles). Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Cc: <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/80822a9353926c38fd7a152991c6292491a9d0e8.1558028966.git.jpoimboe@redhat.com Link: ClangBuiltLinux/linux#481 Signed-off-by: Ingo Molnar <[email protected]>

As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> # build Tested-by: Nick Desaulniers <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]>

LLVM implemented a recent "libcall optimization" that lowers calls to `sprintf(dest, "%s", str)` where the return value is used to `stpcpy(dest, str) - dest`. This generally avoids the machinery involved in parsing format strings. `stpcpy` is just like `strcpy` except it returns the pointer to the new tail of `dest`. This optimization was introduced into clang-12. Implement this so that we don't observe linkage failures due to missing symbol definitions for `stpcpy`. Similar to last year's fire drill with: commit 5f074f3e192f ("lib/string.c: implement a basic bcmp") The kernel is somewhere between a "freestanding" environment (no full libc) and "hosted" environment (many symbols from libc exist with the same type, function signature, and semantics). As H. Peter Anvin notes, there's not really a great way to inform the compiler that you're targeting a freestanding environment but would like to opt-in to some libcall optimizations (see pr/47280 below), rather than opt-out. Arvind notes, -fno-builtin-* behaves slightly differently between GCC and Clang, and Clang is missing many __builtin_* definitions, which I consider a bug in Clang and am working on fixing. Masahiro summarizes the subtle distinction between compilers justly: To prevent transformation from foo() into bar(), there are two ways in Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is only one in GCC; -fno-buitin-foo. (Any difference in that behavior in Clang is likely a bug from a missing __builtin_* definition.) Masahiro also notes: We want to disable optimization from foo() to bar(), but we may still benefit from the optimization from foo() into something else. If GCC implements the same transform, we would run into a problem because it is not -fno-builtin-bar, but -fno-builtin-foo that disables that optimization. In this regard, -fno-builtin-foo would be more future-proof than -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We may want to prevent calls from foo() being optimized into calls to bar(), but we still may want other optimization on calls to foo(). It seems that compilers today don't quite provide the fine grain control over which libcall optimizations pseudo-freestanding environments would prefer. Finally, Kees notes that this interface is unsafe, so we should not encourage its use. As such, I've removed the declaration from any header, but it still needs to be exported to avoid linkage errors in modules. Reported-by: Sami Tolvanen <[email protected]> Suggested-by: Andy Lavr <[email protected]> Suggested-by: Arvind Sankar <[email protected]> Suggested-by: Joe Perches <[email protected]> Suggested-by: Masahiro Yamada <[email protected]> Suggested-by: Rasmus Villemoes <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Acked-by: Kees Cook <[email protected]> Cc: [email protected] Link: https://bugs.llvm.org/show_bug.cgi?id=47162 Link: https://bugs.llvm.org/show_bug.cgi?id=47280 Link: ClangBuiltLinux/linux#1126 Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html Link: https://reviews.llvm.org/D85963

The aarch64linux and aarch64linuxb emulation modes are not supported by bare-metal toolchains and Linux using them forbids building the kernel with these toolchains. Since there is apparently no reason to target these emulation modes, the more generic elf modes are used instead, allowing to build on bare-metal toolchains as well as the already-supported ones. Fixes: 3d6a7b9 ("arm64: ensure the kernel is compiled for LP64") Cc: [email protected] Acked-by: Will Deacon <[email protected]> Signed-off-by: Paul Kocialkowski <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>

With the recent syntax extension, Kconfig is now able to evaluate the compiler / toolchain capability. However, accumulating flags to 'LD' is not compatible with the way it works; 'LD' must be passed to Kconfig to call $(ld-option,...) from Kconfig files. If you tweak 'LD' in arch Makefile depending on CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency between Makefile and Kconfig. Acked-by: Will Deacon <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>

This reverts commit 38fc4248677552ce35efc09902fdcb06b61d7ef9. Distributions such as Fedora and Debian do not package the ELF linker scripts with their toolchains, resulting in kernel build failures such as: | CHK include/generated/compile.h | LD [M] arch/arm64/crypto/sha512-ce.o | aarch64-linux-gnu-ld: cannot open linker script file ldscripts/aarch64elf.xr: No such file or directory | make[1]: *** [scripts/Makefile.build:530: arch/arm64/crypto/sha512-ce.o] Error 1 | make: *** [Makefile:1029: arch/arm64/crypto] Error 2 Revert back to the linux targets for now, adding a comment to the Makefile so we don't accidentally break this in the future. Cc: Paul Kocialkowski <[email protected]> Cc: <[email protected]> Fixes: 38fc42486775 ("arm64: Use aarch64elf and aarch64elfb emulation mode variants") Tested-by: Kevin Hilman <[email protected]> Signed-off-by: Laura Abbott <[email protected]> Signed-off-by: Will Deacon <[email protected]>

commit 0294e6f4a0006856e1f36b8cd8fa088d9e499e98 upstream. Currently, linker options are tested by the coordination of $(CC) and $(LD) because $(LD) needs some object to link. As commit 86a9df597cdd ("kbuild: fix linker feature test macros when cross compiling with Clang") addressed, we need to make sure $(CC) and $(LD) agree the underlying architecture of the passed object. This could be a bit complex when we combine tools from different groups. For example, we can use clang for $(CC), but we still need to rely on GCC toolchain for $(LD). So, I was searching for a way of standalone testing of linker options. A trick I found is to use '-v'; this not only prints the version string, but also tests if the given option is recognized. If a given option is supported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706 $ echo $? 0 If unsupported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1 aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419' aarch64-linux-gnu-ld: use the --help option for usage information $ echo $? 1 Gold works likewise. $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 masahiro@pug:~/ref/linux$ echo $? 0 $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option aarch64-linux-gnu-ld.gold: use the --help option for usage information $ echo $? 1 LLD too. $ ld.lld -v --gc-sections LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-843419 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-999999 ld.lld: error: unknown argument: --fix-cortex-a53-999999 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 1 Signed-off-by: Masahiro Yamada <[email protected]> Tested-by: Nick Desaulniers <[email protected]> [nc: try-run-cached was added later, just use try-run, which is the current mainline state] Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

…able Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in particular. So, probe for whether it's available and use the previous (linux) targets if it isn't. Reported-by: Laura Abbott <[email protected]> Tested-by: Laura Abbott <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Cc: Paul Kocialkowski <[email protected]> Signed-off-by: Olof Johansson <[email protected]> Signed-off-by: Will Deacon <[email protected]>

@grsecurity

commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream. Allow user to use alternative implementations of compression tools, such as pigz, pbzip2, pxz. For example, multi-threaded tools to speed up the build: $ make KGZIP=pigz KBZIP2=pbzip2 Variables KGZIP, KBZIP2, KLZOP are used internally because original env vars are reserved by the tools. The use of GZIP in gzip tool is obsolete since 2015. However, alternative implementations (e.g., pigz) still rely on it. BZIP2, BZIP, LZOP vars are not obsolescent. The credit goes to @grsecurity. As a sidenote, for multi-threaded lzma, xz compression one can use: $ export XZ_OPT="--threads=0" Signed-off-by: Denis Efremov <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Matthias Maennich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Since GCC 9, the compiler warns about evolution of the platform-specific ABI, in particular relating for the marshaling of certain structures involving bitfields. The kernel is a standalone binary, and of course nobody would be so stupid as to expose structs containing bitfields as function arguments in ABI. (Passing a pointer to such a struct, however inadvisable, should be unaffected by this change. perf and various drivers rely on that.) So these warnings do more harm than good: turn them off. We may miss warnings about future ABI drift, but that's too bad. Future ABI breaks of this class will have to be debugged and fixed the traditional way unless the compiler evolves finer-grained diagnostics. Signed-off-by: Dave Martin <[email protected]> Signed-off-by: Will Deacon <[email protected]>

This is a GCC only option, which warns about ABI changes within GCC, so unconditionally adding it breaks Clang with tons of: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] and link time failures: ld.lld: error: undefined symbol: __efistub___stack_chk_guard >>> referenced by arm-stub.c:73 (/home/nathan/cbl/linux/drivers/firmware/efi/libstub/arm-stub.c:73) >>> arm-stub.stub.o:(__efistub_install_memreserve_table) in archive ./drivers/firmware/efi/libstub/lib.a These failures come from the lack of -fno-stack-protector, which is added via cc-option in drivers/firmware/efi/libstub/Makefile. When an unknown flag is added to KBUILD_CFLAGS, clang will noisily warn that it is ignoring the option like above, unlike gcc, who will just error. $ echo "int main() { return 0; }" > tmp.c $ clang -Wno-psabi tmp.c; echo $? warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] 1 warning generated. 0 $ gcc -Wsometimes-uninitialized tmp.c; echo $? gcc: error: unrecognized command line option ‘-Wsometimes-uninitialized’; did you mean ‘-Wmaybe-uninitialized’? 1 For cc-option to work properly with clang and behave like gcc, -Werror is needed, which was done in commit c3f0d0b ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"). $ clang -Werror -Wno-psabi tmp.c; echo $? error: unknown warning option '-Wno-psabi' [-Werror,-Wunknown-warning-option] 1 As a consequence of this, when an unknown flag is unconditionally added to KBUILD_CFLAGS, it will cause cc-option to always fail and those flags will never get added: $ clang -Werror -Wno-psabi -fno-stack-protector tmp.c; echo $? error: unknown warning option '-Wno-psabi' [-Werror,-Wunknown-warning-option] 1 This can be seen when compiling the whole kernel as some warnings that are normally disabled (see below) show up. The full list of flags missing from drivers/firmware/efi/libstub are the following (gathered from diffing .arm64-stub.o.cmd): -fno-delete-null-pointer-checks -Wno-address-of-packed-member -Wframe-larger-than=2048 -Wno-unused-const-variable -fno-strict-overflow -fno-merge-all-constants -fno-stack-check -Werror=date-time -Werror=incompatible-pointer-types -ffreestanding -fno-stack-protector Use cc-disable-warning so that it gets disabled for GCC and does nothing for Clang. Fixes: ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift") Link: ClangBuiltLinux/linux#511 Reported-by: Qian Cai <[email protected]> Acked-by: Dave Martin <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Will Deacon <[email protected]>

commit 1a263ae60b04de959d9ce9caea4889385eefcc7b upstream. gcc-10 has started warning about conflicting types for a few new built-in functions, particularly 'free()'. This results in warnings like: crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch] because the crypto layer had its local freeing functions called 'free()'. Gcc-10 is in the wrong here, since that function is marked 'static', and thus there is no chance of confusion with any standard library function namespace. But the simplest thing to do is to just use a different name here, and avoid this gcc mis-feature. [ Side note: gcc knowing about 'free()' is in itself not the mis-feature: the semantics of 'free()' are special enough that a compiler can validly do special things when seeing it. So the mis-feature here is that gcc thinks that 'free()' is some restricted name, and you can't shadow it as a local static function. Making the special 'free()' semantics be a function attribute rather than tied to the name would be the much better model ] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

Add CONFIG_DISPLAYPORT_DEX_FORCE_WQHD config. Thanks, @fart1-git. Signed-off-by: Denis Efremov <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

[ Upstream commit 6a03469a1edc94da52b65478f1e00837add869a3 ] With CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y, we compile the kernel with -fdata-sections, which also splits the .bss section. The new section, with a new .bss.* name, which pattern gets missed by the main x86 linker script which only expects the '.bss' name. This results in the discarding of the second part and a too small, truncated .bss section and an unhappy, non-working kernel. Use the common BSS_MAIN macro in the linker script to properly capture and merge all the generated BSS sections. Signed-off-by: Sami Tolvanen <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] [ Extended the changelog. ] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

…ections for module build Modules do not tend to cope with -ffunction-sections, even though they do not link with -gc-sections. It may be possible for unused symbols to be trimmed from modules, but in general that would take much more work in architecture module linker scripts. For now, enable these only for kernel build. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

Architectures that are capable can select HAVE_LD_DEAD_CODE_DATA_ELIMINATION to enable selection of that option (as an EXPERT kernel option). Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

Since commit 5d20ee3192a5 ("kbuild: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selectable if enabled"), HAVE_LD_DEAD_CODE_DATA_ELIMINATION is supposed to be selected by architectures that are capable of this functionality. LD_DEAD_CODE_DATA_ELIMINATION is now users' selection. Update the help message. Signed-off-by: Masahiro Yamada <[email protected]>

Signed-off-by: Denis Efremov <[email protected]>

KEEP more tables, and add the function/data section wildcard to more section selections. This is a little ad-hoc at the moment, but kernel code should be moved to consistently use .text..x (note: double dots) for explicit sections and all references to it in the linker script can be made with TEXT_MAIN, and similarly for other sections. For now, let's see if major architectures move to enabling this option then we can do some refactoring passes. Otherwise if it remains unused or superseded by LTO, this may not be required. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>

Enabling both CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_GCOV_PROFILE_ALL=y results in linker warnings: warning: orphan section `.data..LPBX1' being placed in section `.data..LPBX1'. LD_DEAD_CODE_DATA_ELIMINATION adds compiler flag -fdata-sections. This option causes GCC to create separate data sections for data objects, including those generated by GCC internally for gcov profiling. The names of these objects start with a dot (.LPBX0, .LPBX1), resulting in section names starting with 'data..'. As section names starting with 'data..' are used for specific purposes in the Linux kernel, the linker script does not automatically include them in the output data section, resulting in the "orphan section" linker warnings. Fix this by specifically including sections named "data..LPBX*" in the data section. Reported-by: Stephen Rothwell <[email protected]> Tested-by: Stephen Rothwell <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Stephen Rothwell <[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]>

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]>

Commits on Jan 5, 2023

Update main.yml

ridwan20 authored Jan 5, 2023

Configuration menu

View commit details

Copy full SHA for d9db072

Browse repository at this point

Copy the full SHA

d9db072 View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

wont boot on N976x #213

wont boot on N976x #213

Commits on Dec 15, 2022

Commits on Jan 5, 2023

Commits on Apr 28, 2023

Commits on Sep 4, 2023

Commits on Nov 21, 2023

wont boot on N976x #213

Are you sure you want to change the base?

wont boot on N976x #213

Commits on Dec 15, 2022

Commits on Jan 5, 2023

Commits on Apr 28, 2023

Commits on Sep 4, 2023

Commits on Nov 21, 2023