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

Merge tag 'clang-features-v5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2021-06-30T21:33:25Z

Pull clang feature updates from Kees Cook: - Add CC_HAS_NO_PROFILE_FN_ATTR in preparation for PGO support in the face of the noinstr attribute, paving the way for PGO and fixing GCOV. (Nick Desaulniers) - x86_64 LTO coverage is expanded to 32-bit x86. (Nathan Chancellor) - Small fixes to CFI. (Mark Rutland, Nathan Chancellor) * tag 'clang-features-v5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTR compiler_attributes.h: cleanups for GCC 4.9+ compiler_attributes.h: define __no_profile, add to noinstr x86, lto: Enable Clang LTO for 32-bit as well CFI: Move function_nocfi() into compiler.h MAINTAINERS: Add Clang CFI section

CFI: Move function_nocfi() into compiler.h

2021-06-14T16:12:09Z

Currently the common definition of function_nocfi() is provided by , and architectures are expected to provide a definition in . Due to header dependencies, this can make it hard to use function_nocfi() in low-level headers. As function_nocfi() has no dependency on any mm code, nor on any memory definitions, it doesn't need to live in or . Generally, it would make more sense for it to live in , where an architecture can override it in . Move the definitions accordingly. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Kees Cook Cc: Nathan Chancellor Cc: Sami Tolvanen Cc: Will Deacon Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210602153701.35957-1-mark.rutland@arm.com

compiler.h: Avoid using inline asm operand modifiers

2021-05-19T20:30:58Z

The expansion of annotate_reachable/annotate_unreachable on s390 will result in a compiler error if the __COUNTER__ value is high enough. For example with "i" (154) the "%c0" operand of annotate_reachable will be expanded to -102: -102: .pushsection .discard.reachable .long -102b - . .popsection This is a quirk of the gcc backend for s390, it interprets the %c0 as a signed byte value. Avoid using operand modifiers in this case by simply converting __COUNTER__ to string, with the same result, but in an arch assembler independent way. Signed-off-by: Vasily Gorbik Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/patch-1.thread-1a26be.git-930d1b44844a.your-ad-here.call-01621428935-ext-2104@work.hours Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Miroslav Benes Cc: Borislav Petkov Cc: linux-kernel@vger.kernel.org

jump_label: Do not profile branch annotations

2021-01-22T10:08:56Z

While running my branch profiler that checks for incorrect "likely" and "unlikely"s around the kernel, there's a large number of them that are incorrect due to being "static_branches". As static_branches are rather special, as they are likely or unlikely for other reasons than normal annotations are used for, there's no reason to have them be profiled. Expose the "unlikely_notrace" and "likely_notrace" so that the static_branch can use them, and have them be ignored by the branch profilers. Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20201211163754.585174b9@gandalf.local.home

compiler.h: fix barrier_data() on clang

2020-11-14T19:26:03Z

Commit 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") neglected to copy barrier_data() from compiler-gcc.h into compiler-clang.h. The definition in compiler-gcc.h was really to work around clang's more aggressive optimization, so this broke barrier_data() on clang, and consequently memzero_explicit() as well. For example, this results in at least the memzero_explicit() call in lib/crypto/sha256.c:sha256_transform() being optimized away by clang. Fix this by moving the definition of barrier_data() into compiler.h. Also move the gcc/clang definition of barrier() into compiler.h, __memory_barrier() is icc-specific (and barrier() is already defined using it in compiler-intel.h) and doesn't belong in compiler.h. [rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled] Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually exclusive") Signed-off-by: Arvind Sankar Signed-off-by: Randy Dunlap Signed-off-by: Andrew Morton Tested-by: Nick Desaulniers Reviewed-by: Nick Desaulniers Reviewed-by: Kees Cook Cc: Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.edu Signed-off-by: Linus Torvalds

treewide: Convert macro and uses of section(foo) to section("foo")

2020-10-25T21:51:49Z

Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Conversion done using the script at: https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl Signed-off-by: Joe Perches Reviewed-by: Nick Desaulniers Reviewed-by: Miguel Ojeda Signed-off-by: Linus Torvalds

compiler.h: avoid escaped section names

2020-10-14T01:38:26Z

The stringification operator, `#`, in the preprocessor escapes strings. For example, `# "foo"` becomes `"\"foo\""`. GCC and Clang differ in how they treat section names that contain \". The portable solution is to not use a string literal with the preprocessor stringification operator. In this case, since __section unconditionally uses the stringification operator, we actually want the more verbose __attribute__((__section__())). Fixes: commit e04462fb82f8 ("Compiler Attributes: remove uses of __attribute__ from compiler.h") Signed-off-by: Nick Desaulniers Signed-off-by: Andrew Morton Cc: Miguel Ojeda Cc: Luc Van Oostenryck Cc: Nathan Chancellor Cc: Arvind Sankar Link: https://bugs.llvm.org/show_bug.cgi?id=42950 Link: https://lkml.kernel.org/r/20200929194318.548707-1-ndesaulniers@google.com Signed-off-by: Linus Torvalds

compiler.h: Make __ADDRESSABLE() symbol truly unique

2020-09-01T07:58:04Z

The __ADDRESSABLE() macro uses the __LINE__ macro to create a temporary symbol which has a unique name. However, if the macro is used multiple times from within another macro, the line number will always be the same, resulting in duplicate symbols. Make the temporary symbols truly unique by using __UNIQUE_ID instead of __LINE__. Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20200818135804.564436253@infradead.org

Merge tag 'core-headers-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-08-03T21:25:40Z

Pull header cleanup from Ingo Molnar: "Separate out the instrumentation_begin()/end() bits from compiler.h" * tag 'core-headers-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: compiler.h: Move instrumentation_begin()/end() to new header

compiler.h: Move instrumentation_begin()/end() to new header

2020-07-24T11:56:23Z

Linus pointed out that compiler.h - which is a key header that gets included in every single one of the 28,000+ kernel files during a kernel build - was bloated in: 655389666643: ("vmlinux.lds.h: Create section for protection against instrumentation") Linus noted: > I have pulled this, but do we really want to add this to a header file > that is _so_ core that it gets included for basically every single > file built? > > I don't even see those instrumentation_begin/end() things used > anywhere right now. > > It seems excessive. That 53 lines is maybe not a lot, but it pushed > that header file to over 12kB, and while it's mostly comments, it's > extra IO and parsing basically for _every_ single file compiled in the > kernel. > > For what appears to be absolutely zero upside right now, and I really > don't see why this should be in such a core header file! Move these primitives into a new header: , and include that header in the headers that make use of it. Unfortunately one of these headers is asm-generic/bug.h, which does get included in a lot of places, similarly to compiler.h. So the de-bloating effect isn't as good as we'd like it to be - but at least the interfaces are defined separately. No change to functionality intended. Reported-by: Linus Torvalds Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200604071921.GA1361070@gmail.com Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Peter Zijlstra