user/sven/linux.git/include/linux/compiler.h, branch v5.3.2

include/linux/compiler.h: fix Oops for Clang-compiled kernels

2019-09-08T12:53:58Z

GCC unescapes escaped string section names while Clang does not. Because __section uses the `#` stringification operator for the section name, it doesn't need to be escaped. This fixes an Oops observed in distro's that use systemd and not net.core.bpf_jit_enable=1, when their kernels are compiled with Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/619 Link: https://bugs.llvm.org/show_bug.cgi?id=42950 Link: https://marc.info/?l=linux-netdev&m=156412960619946&w=2 Link: https://lore.kernel.org/lkml/20190904181740.GA19688@gmail.com/ Acked-by: Will Deacon Reported-by: Sedat Dilek Suggested-by: Josh Poimboeuf Tested-by: Sedat Dilek Signed-off-by: Nick Desaulniers [Cherry-picked from the __section cleanup series for 5.3] [Adjusted commit message] Signed-off-by: Miguel Ojeda

objtool: Add support for C jump tables

2019-07-09T11:55:46Z

Objtool doesn't know how to read C jump tables, so it has to whitelist functions which use them, causing missing ORC unwinder data for such functions, e.g. ___bpf_prog_run(). C jump tables are very similar to GCC switch jump tables, which objtool already knows how to read. So adding support for C jump tables is easy. It just needs to be able to find the tables and distinguish them from other data. To allow the jump tables to be found, create an __annotate_jump_table macro which can be used to annotate them. The annotation is done by placing the jump table in an .rodata..c_jump_table section. The '.rodata' prefix ensures that the data will be placed in the rodata section by the vmlinux linker script. The double periods are part of an existing convention which distinguishes kernel sections from GCC sections. Signed-off-by: Josh Poimboeuf Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Song Liu Cc: Kairui Song Cc: Steven Rostedt Cc: Borislav Petkov Cc: Alexei Starovoitov Cc: Daniel Borkmann Link: https://lkml.kernel.org/r/0ba2ca30442b16b97165992381ce643dc27b3d1a.1561685471.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar

tracing: Simplify "if" macro code

2019-05-09T19:25:13Z

Peter Zijlstra noticed that with CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the conditional to an array index. This can cause GCC to create horrible code. When there are nested ifs, the generated code uses register values to encode branching decisions. Josh Poimboeuf found that replacing the define "if" macro from using the condition as an array index and incrementing the branch statics with an if statement itself, reduced the asm complexity and shrinks the generated code quite a bit. But this can be simplified even further by replacing the internal if statement with a ternary operator. Link: https://lkml.kernel.org/r/20190307174802.46fmpysxyo35hh43@treble Link: http://lkml.kernel.org/r/CAHk-=wiALN3jRuzARpwThN62iKd476Xj-uom+YnLZ4=eqcz7xQ@mail.gmail.com Reported-by: Peter Zijlstra (Intel) Reported-by: Josh Poimboeuf Signed-off-by: Linus Torvalds Signed-off-by: Steven Rostedt (VMware)

include/linux/compiler*.h: fix OPTIMIZER_HIDE_VAR

2019-01-09T10:36:41Z

Since commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") clang no longer reuses the OPTIMIZER_HIDE_VAR macro from compiler-gcc - instead it gets the version in include/linux/compiler.h. Unfortunately that version doesn't actually prevent compiler from optimizing out the variable. Fix up by moving the macro out from compiler-gcc.h to compiler.h. Compilers without incline asm support will keep working since it's protected by an ifdef. Also fix up comments to match reality since we are no longer overriding any macros. Build-tested with gcc and clang. Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Cc: Eli Friedman Cc: Joe Perches Cc: Linus Torvalds Reviewed-by: Nick Desaulniers Signed-off-by: Michael S. Tsirkin Signed-off-by: Miguel Ojeda

Revert "x86/objtool: Use asm macros to work around GCC inlining bugs"

2018-12-19T11:00:23Z

This reverts commit c06c4d8090513f2974dfdbed2ac98634357ac475. See this commit for details about the revert: e769742d3584 ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"") Reported-by: Masahiro Yamada Reviewed-by: Borislav Petkov Reviewed-by: Thomas Gleixner Cc: Juergen Gross Cc: Richard Biener Cc: Kees Cook Cc: Segher Boessenkool Cc: Ard Biesheuvel Cc: Peter Zijlstra Cc: Josh Poimboeuf Cc: Nadav Amit Cc: Linus Torvalds Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

compiler: remove __no_sanitize_address_or_inline again

2018-11-05T16:14:18Z

The __no_sanitize_address_or_inline and __no_kasan_or_inline defines are almost identical. The only difference is that __no_kasan_or_inline does not have the 'notrace' attribute. To be able to replace __no_sanitize_address_or_inline with the older definition, add 'notrace' to __no_kasan_or_inline and change to two users of __no_sanitize_address_or_inline in the s390 code. The 'notrace' option is necessary for e.g. the __load_psw_mask function in arch/s390/include/asm/processor.h. Without the option it is possible to trace __load_psw_mask which leads to kernel stack overflow. Signed-off-by: Martin Schwidefsky Pointed-out-by: Andrey Ryabinin Acked-by: Steven Rostedt (VMware) Signed-off-by: Linus Torvalds

Merge tag 'compiler-attributes-for-linus-4.20-rc1' of https://github.com/ojeda/linux

2018-11-02T01:34:46Z

Pull compiler attribute updates from Miguel Ojeda: "This is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION), which are compiler-agnostic (so they can be shared, reducing the size of compiler-specific headers) and version-agnostic. Other related improvements have been performed in the headers as well, which on top of the use of __has_attribute it has amounted to a significant simplification of these headers (e.g. GCC_VERSION is now only guarding a few non-attribute macros). This series should also help the efforts to support compiling the kernel with clang and icc. A fair amount of documentation and comments have also been added, clarified or removed; and the headers are now more readable, which should help kernel developers in general. The series was triggered due to the move to gcc >= 4.6. In turn, this series has also triggered Sparse to gain the ability to recognize __has_attribute on its own. Finally, the __nonstring variable attribute series has been also applied on top; plus two related patches from Nick Desaulniers for unreachable() that came a bit afterwards" * tag 'compiler-attributes-for-linus-4.20-rc1' of https://github.com/ojeda/linux: compiler-gcc: remove comment about gcc 4.5 from unreachable() compiler.h: update definition of unreachable() Compiler Attributes: ext4: remove local __nonstring definition Compiler Attributes: auxdisplay: panel: use __nonstring Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8) Compiler Attributes: add support for __nonstring (gcc >= 8) Compiler Attributes: add MAINTAINERS entry Compiler Attributes: add Doc/process/programming-language.rst Compiler Attributes: remove uses of __attribute__ from compiler.h Compiler Attributes: KENTRY used twice the "used" attribute Compiler Attributes: use feature checks instead of version checks Compiler Attributes: add missing SPDX ID in compiler_types.h Compiler Attributes: remove unneeded sparse (__CHECKER__) tests Compiler Attributes: homogenize __must_be_array Compiler Attributes: remove unneeded tests Compiler Attributes: always use the extra-underscores syntax Compiler Attributes: remove unused attributes

Merge tag 'vla-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2018-10-28T20:26:45Z

Pull VLA removal from Kees Cook: "Globally warn on VLA use. This turns on "-Wvla" globally now that the last few trees with their VLA removals have landed (crypto, block, net, and powerpc). Arnd mentioned that there may be a couple more VLAs hiding in hard-to-find randconfigs, but nothing big has shaken out in the last month or so in linux-next. We should be basically VLA-free now! Wheee. :) Summary: - Remove unused fallback for BUILD_BUG_ON (which technically contains a VLA) - Lift -Wvla to the top-level Makefile" * tag 'vla-v4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: Makefile: Globally enable VLA warning compiler.h: give up __compiletime_assert_fallback()

compiler.h: update definition of unreachable()

2018-10-19T06:47:14Z

Fixes the objtool warning seen with Clang: arch/x86/mm/fault.o: warning: objtool: no_context()+0x220: unreachable instruction Fixes commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Josh noted that the fallback definition was meant to work around a pre-gcc-4.6 bug. GCC still needs to work around https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365, so compiler-gcc.h defines its own version of unreachable(). Clang and ICC can use this shared definition. Link: https://github.com/ClangBuiltLinux/linux/issues/204 Suggested-by: Andy Lutomirski Suggested-by: Josh Poimboeuf Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Miguel Ojeda

compiler.h: give up __compiletime_assert_fallback()

2018-10-11T15:17:50Z

__compiletime_assert_fallback() is supposed to stop building earlier by using the negative-array-size method in case the compiler does not support "error" attribute, but has never worked like that. You can simply try: BUILD_BUG_ON(1); GCC immediately terminates the build, but Clang does not report anything because Clang does not support the "error" attribute now. It will later fail at link time, but __compiletime_assert_fallback() is not working at least. The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON() was checked by the negative-array-size method *and* the link-time trick. Since that commit, the negative-array-size is not effective because '__cond' is no longer constant. As the comment in says, GCC (and Clang as well) only emits the error for obvious cases. When '__cond' is a variable, ((void)sizeof(char[1 - 2 * __cond])) ... is not obvious for the compiler to know the array size is negative. Reverting that commit would break BUILD_BUG() because negative-size-array is evaluated before the code is optimized out. Let's give up __compiletime_assert_fallback(). This commit does not change the current behavior since it just rips off the useless code. Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Reviewed-by: Nick Desaulniers Signed-off-by: Kees Cook