2005-04-17 06:20:36 +08:00
|
|
|
#ifndef __LINUX_COMPILER_H
|
|
|
|
|
#define __LINUX_COMPILER_H
|
|
|
|
|
|
linux/compiler.h: Split into compiler.h and compiler_types.h
linux/compiler.h is included indirectly by linux/types.h via
uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h
-> uapi/linux/stddef.h and is needed to provide a proper definition of
offsetof.
Unfortunately, compiler.h requires a definition of
smp_read_barrier_depends() for defining lockless_dereference() and soon
for defining READ_ONCE(), which means that all
users of READ_ONCE() will need to include asm/barrier.h to avoid splats
such as:
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from arch/h8300/kernel/asm-offsets.c:11:
include/linux/list.h: In function 'list_empty':
>> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration]
smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
^
A better alternative is to include asm/barrier.h in linux/compiler.h,
but this requires a type definition for "bool" on some architectures
(e.g. x86), which is defined later by linux/types.h. Type "bool" is also
used directly in linux/compiler.h, so the whole thing is pretty fragile.
This patch splits compiler.h in two: compiler_types.h contains type
annotations, definitions and the compiler-specific parts, whereas
compiler.h #includes compiler-types.h and additionally defines macros
such as {READ,WRITE.ACCESS}_ONCE().
uapi/linux/stddef.h and linux/linkage.h are then moved over to include
linux/compiler_types.h, which fixes the build for h8 and blackfin.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 18:22:46 +08:00
|
|
|
#include <linux/compiler_types.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
linux/compiler.h: Split into compiler.h and compiler_types.h
linux/compiler.h is included indirectly by linux/types.h via
uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h
-> uapi/linux/stddef.h and is needed to provide a proper definition of
offsetof.
Unfortunately, compiler.h requires a definition of
smp_read_barrier_depends() for defining lockless_dereference() and soon
for defining READ_ONCE(), which means that all
users of READ_ONCE() will need to include asm/barrier.h to avoid splats
such as:
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from arch/h8300/kernel/asm-offsets.c:11:
include/linux/list.h: In function 'list_empty':
>> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration]
smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
^
A better alternative is to include asm/barrier.h in linux/compiler.h,
but this requires a type definition for "bool" on some architectures
(e.g. x86), which is defined later by linux/types.h. Type "bool" is also
used directly in linux/compiler.h, so the whole thing is pretty fragile.
This patch splits compiler.h in two: compiler_types.h contains type
annotations, definitions and the compiler-specific parts, whereas
compiler.h #includes compiler-types.h and additionally defines macros
such as {READ,WRITE.ACCESS}_ONCE().
uapi/linux/stddef.h and linux/linkage.h are then moved over to include
linux/compiler_types.h, which fixes the build for h8 and blackfin.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 18:22:46 +08:00
|
|
|
#ifndef __ASSEMBLY__
|
2012-11-22 10:00:25 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifdef __KERNEL__
|
|
|
|
|
|
2008-11-13 04:24:24 +08:00
|
|
|
/*
|
|
|
|
|
* Note: DISABLE_BRANCH_PROFILING can be used by special lowlevel code
|
|
|
|
|
* to disable branch tracing on a per file basis.
|
|
|
|
|
*/
|
2009-04-05 22:20:02 +08:00
|
|
|
#if defined(CONFIG_TRACE_BRANCH_PROFILING) \
|
|
|
|
|
&& !defined(DISABLE_BRANCH_PROFILING) && !defined(__CHECKER__)
|
2017-01-19 21:57:14 +08:00
|
|
|
void ftrace_likely_update(struct ftrace_likely_data *f, int val,
|
tracing: Process constants for (un)likely() profiler
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:
#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.
By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-01-18 01:29:35 +08:00
|
|
|
int expect, int is_constant);
|
2008-11-12 13:14:39 +08:00
|
|
|
|
|
|
|
|
#define likely_notrace(x) __builtin_expect(!!(x), 1)
|
|
|
|
|
#define unlikely_notrace(x) __builtin_expect(!!(x), 0)
|
|
|
|
|
|
tracing: Process constants for (un)likely() profiler
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:
#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.
By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-01-18 01:29:35 +08:00
|
|
|
#define __branch_check__(x, expect, is_constant) ({ \
|
2008-11-12 13:14:39 +08:00
|
|
|
int ______r; \
|
2017-01-19 21:57:14 +08:00
|
|
|
static struct ftrace_likely_data \
|
2008-11-12 13:14:39 +08:00
|
|
|
__attribute__((__aligned__(4))) \
|
2008-11-21 13:40:40 +08:00
|
|
|
__attribute__((section("_ftrace_annotated_branch"))) \
|
2008-11-12 13:14:39 +08:00
|
|
|
______f = { \
|
2017-01-19 21:57:14 +08:00
|
|
|
.data.func = __func__, \
|
|
|
|
|
.data.file = __FILE__, \
|
|
|
|
|
.data.line = __LINE__, \
|
2008-11-12 13:14:39 +08:00
|
|
|
}; \
|
tracing: Process constants for (un)likely() profiler
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:
#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.
By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-01-18 01:29:35 +08:00
|
|
|
______r = __builtin_expect(!!(x), expect); \
|
|
|
|
|
ftrace_likely_update(&______f, ______r, \
|
|
|
|
|
expect, is_constant); \
|
2008-11-12 13:14:39 +08:00
|
|
|
______r; \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Using __builtin_constant_p(x) to ignore cases where the return
|
|
|
|
|
* value is always the same. This idea is taken from a similar patch
|
|
|
|
|
* written by Daniel Walker.
|
|
|
|
|
*/
|
|
|
|
|
# ifndef likely
|
tracing: Process constants for (un)likely() profiler
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:
#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.
By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-01-18 01:29:35 +08:00
|
|
|
# define likely(x) (__branch_check__(x, 1, __builtin_constant_p(x)))
|
2008-11-12 13:14:39 +08:00
|
|
|
# endif
|
|
|
|
|
# ifndef unlikely
|
tracing: Process constants for (un)likely() profiler
When running the likely/unlikely profiler, one of the results did not look
accurate. It noted that the unlikely() in link_path_walk() was 100%
incorrect. When I added a trace_printk() to see what was happening there, it
became 80% correct! Looking deeper into what whas happening, I found that
gcc split that if statement into two paths. One where the if statement
became a constant, the other path a variable. The other path had the if
statement always hit (making the unlikely there, always false), but since
the #define unlikely() has:
#define unlikely() (__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
Where constants are ignored by the branch profiler, the "constant" path
made by the compiler was ignored, even though it was hit 80% of the time.
By just passing the constant value to the __branch_check__() function and
tracing it out of line (as always correct, as likely/unlikely isn't a factor
for constants), then we get back the accurate readings of branches that were
optimized by gcc causing part of the execution to become constant.
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-01-18 01:29:35 +08:00
|
|
|
# define unlikely(x) (__branch_check__(x, 0, __builtin_constant_p(x)))
|
2008-11-12 13:14:39 +08:00
|
|
|
# endif
|
2008-11-21 14:30:54 +08:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_PROFILE_ALL_BRANCHES
|
|
|
|
|
/*
|
|
|
|
|
* "Define 'is'", Bill Clinton
|
|
|
|
|
* "Define 'if'", Steven Rostedt
|
|
|
|
|
*/
|
2009-04-07 22:59:41 +08:00
|
|
|
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
|
|
|
|
|
#define __trace_if(cond) \
|
tracing: Fix freak link error caused by branch tracer
In my randconfig tests, I came across a bug that involves several
components:
* gcc-4.9 through at least 5.3
* CONFIG_GCOV_PROFILE_ALL enabling -fprofile-arcs for all files
* CONFIG_PROFILE_ALL_BRANCHES overriding every if()
* The optimized implementation of do_div() that tries to
replace a library call with an division by multiplication
* code in drivers/media/dvb-frontends/zl10353.c doing
u32 adc_clock = 450560; /* 45.056 MHz */
if (state->config.adc_clock)
adc_clock = state->config.adc_clock;
do_div(value, adc_clock);
In this case, gcc fails to determine whether the divisor
in do_div() is __builtin_constant_p(). In particular, it
concludes that __builtin_constant_p(adc_clock) is false, while
__builtin_constant_p(!!adc_clock) is true.
That in turn throws off the logic in do_div() that also uses
__builtin_constant_p(), and instead of picking either the
constant- optimized division, and the code in ilog2() that uses
__builtin_constant_p() to figure out whether it knows the answer at
compile time. The result is a link error from failing to find
multiple symbols that should never have been called based on
the __builtin_constant_p():
dvb-frontends/zl10353.c:138: undefined reference to `____ilog2_NaN'
dvb-frontends/zl10353.c:138: undefined reference to `__aeabi_uldivmod'
ERROR: "____ilog2_NaN" [drivers/media/dvb-frontends/zl10353.ko] undefined!
ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/zl10353.ko] undefined!
This patch avoids the problem by changing __trace_if() to check
whether the condition is known at compile-time to be nonzero, rather
than checking whether it is actually a constant.
I see this one link error in roughly one out of 1600 randconfig builds
on ARM, and the patch fixes all known instances.
Link: http://lkml.kernel.org/r/1455312410-1058841-1-git-send-email-arnd@arndb.de
Acked-by: Nicolas Pitre <nico@linaro.org>
Fixes: ab3c9c686e22 ("branch tracer, intel-iommu: fix build with CONFIG_BRANCH_TRACER=y")
Cc: stable@vger.kernel.org # v2.6.30+
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2016-02-13 05:26:42 +08:00
|
|
|
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
|
2008-11-21 14:30:54 +08:00
|
|
|
({ \
|
|
|
|
|
int ______r; \
|
|
|
|
|
static struct ftrace_branch_data \
|
|
|
|
|
__attribute__((__aligned__(4))) \
|
|
|
|
|
__attribute__((section("_ftrace_branch"))) \
|
|
|
|
|
______f = { \
|
|
|
|
|
.func = __func__, \
|
|
|
|
|
.file = __FILE__, \
|
|
|
|
|
.line = __LINE__, \
|
|
|
|
|
}; \
|
|
|
|
|
______r = !!(cond); \
|
2009-03-18 04:15:44 +08:00
|
|
|
______f.miss_hit[______r]++; \
|
2008-11-21 14:30:54 +08:00
|
|
|
______r; \
|
|
|
|
|
}))
|
|
|
|
|
#endif /* CONFIG_PROFILE_ALL_BRANCHES */
|
|
|
|
|
|
2008-11-12 13:14:39 +08:00
|
|
|
#else
|
|
|
|
|
# define likely(x) __builtin_expect(!!(x), 1)
|
|
|
|
|
# define unlikely(x) __builtin_expect(!!(x), 0)
|
|
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
/* Optimization barrier */
|
|
|
|
|
#ifndef barrier
|
|
|
|
|
# define barrier() __memory_barrier()
|
|
|
|
|
#endif
|
|
|
|
|
|
lib: make memzero_explicit more robust against dead store elimination
In commit 0b053c951829 ("lib: memzero_explicit: use barrier instead
of OPTIMIZER_HIDE_VAR"), we made memzero_explicit() more robust in
case LTO would decide to inline memzero_explicit() and eventually
find out it could be elimiated as dead store.
While using barrier() works well for the case of gcc, recent efforts
from LLVMLinux people suggest to use llvm as an alternative to gcc,
and there, Stephan found in a simple stand-alone user space example
that llvm could nevertheless optimize and thus elimitate the memset().
A similar issue has been observed in the referenced llvm bug report,
which is regarded as not-a-bug.
Based on some experiments, icc is a bit special on its own, while it
doesn't seem to eliminate the memset(), it could do so with an own
implementation, and then result in similar findings as with llvm.
The fix in this patch now works for all three compilers (also tested
with more aggressive optimization levels). Arguably, in the current
kernel tree it's more of a theoretical issue, but imho, it's better
to be pedantic about it.
It's clearly visible with gcc/llvm though, with the below code: if we
would have used barrier() only here, llvm would have omitted clearing,
not so with barrier_data() variant:
static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
barrier_data(s);
}
int main(void)
{
char buff[20];
memzero_explicit(buff, sizeof(buff));
return 0;
}
$ gcc -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000400400 <+0>: lea -0x28(%rsp),%rax
0x0000000000400405 <+5>: movq $0x0,-0x28(%rsp)
0x000000000040040e <+14>: movq $0x0,-0x20(%rsp)
0x0000000000400417 <+23>: movl $0x0,-0x18(%rsp)
0x000000000040041f <+31>: xor %eax,%eax
0x0000000000400421 <+33>: retq
End of assembler dump.
$ clang -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004f0 <+0>: xorps %xmm0,%xmm0
0x00000000004004f3 <+3>: movaps %xmm0,-0x18(%rsp)
0x00000000004004f8 <+8>: movl $0x0,-0x8(%rsp)
0x0000000000400500 <+16>: lea -0x18(%rsp),%rax
0x0000000000400505 <+21>: xor %eax,%eax
0x0000000000400507 <+23>: retq
End of assembler dump.
As gcc, clang, but also icc defines __GNUC__, it's sufficient to define
this in compiler-gcc.h only to be picked up. For a fallback or otherwise
unsupported compiler, we define it as a barrier. Similarly, for ecc which
does not support gcc inline asm.
Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller <smueller@chronox.de>
Tested-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Stephan Mueller <smueller@chronox.de>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: mancha security <mancha1@zoho.com>
Cc: Mark Charlebois <charlebm@gmail.com>
Cc: Behan Webster <behanw@converseincode.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-04-30 10:13:52 +08:00
|
|
|
#ifndef barrier_data
|
|
|
|
|
# define barrier_data(ptr) barrier()
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-12-05 09:44:50 +08:00
|
|
|
/* Unreachable code */
|
objtool: Assume unannotated UD2 instructions are dead ends
Arnd reported some false positive warnings with GCC 7:
drivers/hid/wacom_wac.o: warning: objtool: wacom_bpt3_touch()+0x2a5: stack state mismatch: cfa1=7+8 cfa2=6+16
drivers/iio/adc/vf610_adc.o: warning: objtool: vf610_adc_calculate_rates() falls through to next function vf610_adc_sample_set()
drivers/pwm/pwm-hibvt.o: warning: objtool: hibvt_pwm_get_state() falls through to next function hibvt_pwm_remove()
drivers/pwm/pwm-mediatek.o: warning: objtool: mtk_pwm_config() falls through to next function mtk_pwm_enable()
drivers/spi/spi-bcm2835.o: warning: objtool: .text: unexpected end of section
drivers/spi/spi-bcm2835aux.o: warning: objtool: .text: unexpected end of section
drivers/watchdog/digicolor_wdt.o: warning: objtool: dc_wdt_get_timeleft() falls through to next function dc_wdt_restart()
When GCC 7 detects a potential divide-by-zero condition, it sometimes
inserts a UD2 instruction for the case where the divisor is zero,
instead of letting the hardware trap on the divide instruction.
Objtool doesn't consider UD2 to be fatal unless it's annotated with
unreachable(). So it considers the GCC-generated UD2 to be non-fatal,
and it tries to follow the control flow past the UD2 and gets
confused.
Previously, objtool *did* assume UD2 was always a dead end. That
changed with the following commit:
d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
The motivation behind that change was that Peter was planning on using
UD2 for __WARN(), which is *not* a dead end. However, it turns out
that some emulators rely on UD2 being fatal, so he ended up using
'ud0' instead:
9a93848fe787 ("x86/debug: Implement __WARN() using UD0")
For GCC 4.5+, it should be safe to go back to the previous assumption
that UD2 is fatal, even when it's not annotated with unreachable().
But for pre-4.5 versions of GCC, the unreachable() macro isn't
supported, so such cases of UD2 need to be explicitly annotated as
reachable.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
Link: http://lkml.kernel.org/r/e57fa9dfede25f79487da8126ee9cdf7b856db65.1501188854.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-28 04:56:53 +08:00
|
|
|
#ifdef CONFIG_STACK_VALIDATION
|
|
|
|
|
#define annotate_reachable() ({ \
|
|
|
|
|
asm("%c0:\n\t" \
|
|
|
|
|
".pushsection .discard.reachable\n\t" \
|
|
|
|
|
".long %c0b - .\n\t" \
|
|
|
|
|
".popsection\n\t" : : "i" (__LINE__)); \
|
|
|
|
|
})
|
|
|
|
|
#define annotate_unreachable() ({ \
|
|
|
|
|
asm("%c0:\n\t" \
|
|
|
|
|
".pushsection .discard.unreachable\n\t" \
|
|
|
|
|
".long %c0b - .\n\t" \
|
|
|
|
|
".popsection\n\t" : : "i" (__LINE__)); \
|
|
|
|
|
})
|
|
|
|
|
#define ASM_UNREACHABLE \
|
|
|
|
|
"999:\n\t" \
|
|
|
|
|
".pushsection .discard.unreachable\n\t" \
|
|
|
|
|
".long 999b - .\n\t" \
|
|
|
|
|
".popsection\n\t"
|
|
|
|
|
#else
|
|
|
|
|
#define annotate_reachable()
|
|
|
|
|
#define annotate_unreachable()
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-07-25 02:35:48 +08:00
|
|
|
#ifndef ASM_UNREACHABLE
|
|
|
|
|
# define ASM_UNREACHABLE
|
|
|
|
|
#endif
|
2009-12-05 09:44:50 +08:00
|
|
|
#ifndef unreachable
|
objtool: Assume unannotated UD2 instructions are dead ends
Arnd reported some false positive warnings with GCC 7:
drivers/hid/wacom_wac.o: warning: objtool: wacom_bpt3_touch()+0x2a5: stack state mismatch: cfa1=7+8 cfa2=6+16
drivers/iio/adc/vf610_adc.o: warning: objtool: vf610_adc_calculate_rates() falls through to next function vf610_adc_sample_set()
drivers/pwm/pwm-hibvt.o: warning: objtool: hibvt_pwm_get_state() falls through to next function hibvt_pwm_remove()
drivers/pwm/pwm-mediatek.o: warning: objtool: mtk_pwm_config() falls through to next function mtk_pwm_enable()
drivers/spi/spi-bcm2835.o: warning: objtool: .text: unexpected end of section
drivers/spi/spi-bcm2835aux.o: warning: objtool: .text: unexpected end of section
drivers/watchdog/digicolor_wdt.o: warning: objtool: dc_wdt_get_timeleft() falls through to next function dc_wdt_restart()
When GCC 7 detects a potential divide-by-zero condition, it sometimes
inserts a UD2 instruction for the case where the divisor is zero,
instead of letting the hardware trap on the divide instruction.
Objtool doesn't consider UD2 to be fatal unless it's annotated with
unreachable(). So it considers the GCC-generated UD2 to be non-fatal,
and it tries to follow the control flow past the UD2 and gets
confused.
Previously, objtool *did* assume UD2 was always a dead end. That
changed with the following commit:
d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
The motivation behind that change was that Peter was planning on using
UD2 for __WARN(), which is *not* a dead end. However, it turns out
that some emulators rely on UD2 being fatal, so he ended up using
'ud0' instead:
9a93848fe787 ("x86/debug: Implement __WARN() using UD0")
For GCC 4.5+, it should be safe to go back to the previous assumption
that UD2 is fatal, even when it's not annotated with unreachable().
But for pre-4.5 versions of GCC, the unreachable() macro isn't
supported, so such cases of UD2 need to be explicitly annotated as
reachable.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
Link: http://lkml.kernel.org/r/e57fa9dfede25f79487da8126ee9cdf7b856db65.1501188854.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-07-28 04:56:53 +08:00
|
|
|
# define unreachable() do { annotate_reachable(); do { } while (1); } while (0)
|
2009-12-05 09:44:50 +08:00
|
|
|
#endif
|
|
|
|
|
|
kbuild: allow archs to select link dead code/data elimination
Introduce LD_DEAD_CODE_DATA_ELIMINATION option for architectures to
select to build with -ffunction-sections, -fdata-sections, and link
with --gc-sections. It requires some work (documented) to ensure all
unreferenced entrypoints are live, and requires toolchain and build
verification, so it is made a per-arch option for now.
On a random powerpc64le build, this yelds a significant size saving,
it boots and runs fine, but there is a lot I haven't tested as yet, so
these savings may be reduced if there are bugs in the link.
text data bss dec filename
11169741 1180744 1923176 14273661 vmlinux
10445269 1004127 1919707 13369103 vmlinux.dce
~700K text, ~170K data, 6% removed from kernel image size.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>
2016-08-24 20:29:20 +08:00
|
|
|
/*
|
|
|
|
|
* KENTRY - kernel entry point
|
|
|
|
|
* This can be used to annotate symbols (functions or data) that are used
|
|
|
|
|
* without their linker symbol being referenced explicitly. For example,
|
|
|
|
|
* interrupt vector handlers, or functions in the kernel image that are found
|
|
|
|
|
* programatically.
|
|
|
|
|
*
|
|
|
|
|
* Not required for symbols exported with EXPORT_SYMBOL, or initcalls. Those
|
|
|
|
|
* are handled in their own way (with KEEP() in linker scripts).
|
|
|
|
|
*
|
|
|
|
|
* KENTRY can be avoided if the symbols in question are marked as KEEP() in the
|
|
|
|
|
* linker script. For example an architecture could KEEP() its entire
|
|
|
|
|
* boot/exception vector code rather than annotate each function and data.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef KENTRY
|
|
|
|
|
# define KENTRY(sym) \
|
|
|
|
|
extern typeof(sym) sym; \
|
|
|
|
|
static const unsigned long __kentry_##sym \
|
|
|
|
|
__used \
|
|
|
|
|
__attribute__((section("___kentry" "+" #sym ), used)) \
|
|
|
|
|
= (unsigned long)&sym;
|
|
|
|
|
#endif
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifndef RELOC_HIDE
|
|
|
|
|
# define RELOC_HIDE(ptr, off) \
|
|
|
|
|
({ unsigned long __ptr; \
|
|
|
|
|
__ptr = (unsigned long) (ptr); \
|
|
|
|
|
(typeof(ptr)) (__ptr + (off)); })
|
|
|
|
|
#endif
|
|
|
|
|
|
2013-11-26 08:00:41 +08:00
|
|
|
#ifndef OPTIMIZER_HIDE_VAR
|
|
|
|
|
#define OPTIMIZER_HIDE_VAR(var) barrier()
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-11-22 10:00:25 +08:00
|
|
|
/* Not-quite-unique ID. */
|
|
|
|
|
#ifndef __UNIQUE_ID
|
|
|
|
|
# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
|
|
|
|
|
#endif
|
|
|
|
|
|
2014-11-25 17:01:16 +08:00
|
|
|
#include <uapi/linux/types.h>
|
|
|
|
|
|
2015-10-19 16:37:17 +08:00
|
|
|
#define __READ_ONCE_SIZE \
|
|
|
|
|
({ \
|
|
|
|
|
switch (size) { \
|
|
|
|
|
case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
|
|
|
|
|
case 2: *(__u16 *)res = *(volatile __u16 *)p; break; \
|
|
|
|
|
case 4: *(__u32 *)res = *(volatile __u32 *)p; break; \
|
|
|
|
|
case 8: *(__u64 *)res = *(volatile __u64 *)p; break; \
|
|
|
|
|
default: \
|
|
|
|
|
barrier(); \
|
|
|
|
|
__builtin_memcpy((void *)res, (const void *)p, size); \
|
|
|
|
|
barrier(); \
|
|
|
|
|
} \
|
|
|
|
|
})
|
|
|
|
|
|
|
|
|
|
static __always_inline
|
|
|
|
|
void __read_once_size(const volatile void *p, void *res, int size)
|
2014-11-25 17:01:16 +08:00
|
|
|
{
|
2015-10-19 16:37:17 +08:00
|
|
|
__READ_ONCE_SIZE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_KASAN
|
|
|
|
|
/*
|
|
|
|
|
* This function is not 'inline' because __no_sanitize_address confilcts
|
|
|
|
|
* with inlining. Attempt to inline it may cause a build failure.
|
|
|
|
|
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
|
|
|
|
|
* '__maybe_unused' allows us to avoid defined-but-not-used warnings.
|
|
|
|
|
*/
|
|
|
|
|
static __no_sanitize_address __maybe_unused
|
|
|
|
|
void __read_once_size_nocheck(const volatile void *p, void *res, int size)
|
|
|
|
|
{
|
|
|
|
|
__READ_ONCE_SIZE;
|
|
|
|
|
}
|
|
|
|
|
#else
|
|
|
|
|
static __always_inline
|
|
|
|
|
void __read_once_size_nocheck(const volatile void *p, void *res, int size)
|
|
|
|
|
{
|
|
|
|
|
__READ_ONCE_SIZE;
|
2014-11-25 17:01:16 +08:00
|
|
|
}
|
2015-10-19 16:37:17 +08:00
|
|
|
#endif
|
2014-11-25 17:01:16 +08:00
|
|
|
|
2015-01-13 17:46:42 +08:00
|
|
|
static __always_inline void __write_once_size(volatile void *p, void *res, int size)
|
2014-11-25 17:01:16 +08:00
|
|
|
{
|
|
|
|
|
switch (size) {
|
|
|
|
|
case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
|
|
|
|
|
case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
|
|
|
|
|
case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
|
|
|
|
|
case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
|
|
|
|
|
default:
|
|
|
|
|
barrier();
|
|
|
|
|
__builtin_memcpy((void *)p, (const void *)res, size);
|
|
|
|
|
barrier();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Prevent the compiler from merging or refetching reads or writes. The
|
|
|
|
|
* compiler is also forbidden from reordering successive instances of
|
2015-01-13 17:46:42 +08:00
|
|
|
* READ_ONCE, WRITE_ONCE and ACCESS_ONCE (see below), but only when the
|
2014-11-25 17:01:16 +08:00
|
|
|
* compiler is aware of some particular ordering. One way to make the
|
|
|
|
|
* compiler aware of ordering is to put the two invocations of READ_ONCE,
|
2015-01-13 17:46:42 +08:00
|
|
|
* WRITE_ONCE or ACCESS_ONCE() in different C statements.
|
2014-11-25 17:01:16 +08:00
|
|
|
*
|
|
|
|
|
* In contrast to ACCESS_ONCE these two macros will also work on aggregate
|
|
|
|
|
* data types like structs or unions. If the size of the accessed data
|
|
|
|
|
* type exceeds the word size of the machine (e.g., 32 bits or 64 bits)
|
2016-01-26 05:33:20 +08:00
|
|
|
* READ_ONCE() and WRITE_ONCE() will fall back to memcpy(). There's at
|
|
|
|
|
* least two memcpy()s: one for the __builtin_memcpy() and then one for
|
|
|
|
|
* the macro doing the copy of variable - '__u' allocated on the stack.
|
2014-11-25 17:01:16 +08:00
|
|
|
*
|
|
|
|
|
* Their two major use cases are: (1) Mediating communication between
|
|
|
|
|
* process-level code and irq/NMI handlers, all running on the same CPU,
|
|
|
|
|
* and (2) Ensuring that the compiler does not fold, spindle, or otherwise
|
|
|
|
|
* mutilate accesses that either do not require ordering or that interact
|
|
|
|
|
* with an explicit memory barrier or atomic instruction that provides the
|
|
|
|
|
* required ordering.
|
|
|
|
|
*/
|
linux/compiler.h: Split into compiler.h and compiler_types.h
linux/compiler.h is included indirectly by linux/types.h via
uapi/linux/types.h -> uapi/linux/posix_types.h -> linux/stddef.h
-> uapi/linux/stddef.h and is needed to provide a proper definition of
offsetof.
Unfortunately, compiler.h requires a definition of
smp_read_barrier_depends() for defining lockless_dereference() and soon
for defining READ_ONCE(), which means that all
users of READ_ONCE() will need to include asm/barrier.h to avoid splats
such as:
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from arch/h8300/kernel/asm-offsets.c:11:
include/linux/list.h: In function 'list_empty':
>> include/linux/compiler.h:343:2: error: implicit declaration of function 'smp_read_barrier_depends' [-Werror=implicit-function-declaration]
smp_read_barrier_depends(); /* Enforce dependency ordering from x */ \
^
A better alternative is to include asm/barrier.h in linux/compiler.h,
but this requires a type definition for "bool" on some architectures
(e.g. x86), which is defined later by linux/types.h. Type "bool" is also
used directly in linux/compiler.h, so the whole thing is pretty fragile.
This patch splits compiler.h in two: compiler_types.h contains type
annotations, definitions and the compiler-specific parts, whereas
compiler.h #includes compiler-types.h and additionally defines macros
such as {READ,WRITE.ACCESS}_ONCE().
uapi/linux/stddef.h and linux/linkage.h are then moved over to include
linux/compiler_types.h, which fixes the build for h8 and blackfin.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1508840570-22169-2-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-10-24 18:22:46 +08:00
|
|
|
#include <asm/barrier.h>
|
2014-11-25 17:01:16 +08:00
|
|
|
|
2015-10-19 16:37:17 +08:00
|
|
|
#define __READ_ONCE(x, check) \
|
|
|
|
|
({ \
|
|
|
|
|
union { typeof(x) __val; char __c[1]; } __u; \
|
|
|
|
|
if (check) \
|
|
|
|
|
__read_once_size(&(x), __u.__c, sizeof(x)); \
|
|
|
|
|
else \
|
|
|
|
|
__read_once_size_nocheck(&(x), __u.__c, sizeof(x)); \
|
|
|
|
|
__u.__val; \
|
|
|
|
|
})
|
|
|
|
|
#define READ_ONCE(x) __READ_ONCE(x, 1)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need
|
|
|
|
|
* to hide memory access from KASAN.
|
|
|
|
|
*/
|
|
|
|
|
#define READ_ONCE_NOCHECK(x) __READ_ONCE(x, 0)
|
2014-11-25 17:01:16 +08:00
|
|
|
|
2015-01-13 17:46:42 +08:00
|
|
|
#define WRITE_ONCE(x, val) \
|
2015-08-04 15:55:48 +08:00
|
|
|
({ \
|
|
|
|
|
union { typeof(x) __val; char __c[1]; } __u = \
|
|
|
|
|
{ .__val = (__force typeof(x)) (val) }; \
|
|
|
|
|
__write_once_size(&(x), __u.__c, sizeof(x)); \
|
|
|
|
|
__u.__val; \
|
|
|
|
|
})
|
2014-11-25 17:01:16 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* __KERNEL__ */
|
|
|
|
|
|
|
|
|
|
#endif /* __ASSEMBLY__ */
|
|
|
|
|
|
2009-09-26 20:33:01 +08:00
|
|
|
/* Compile time object size, -1 for unknown */
|
|
|
|
|
#ifndef __compiletime_object_size
|
|
|
|
|
# define __compiletime_object_size(obj) -1
|
|
|
|
|
#endif
|
2009-09-30 19:05:23 +08:00
|
|
|
#ifndef __compiletime_warning
|
|
|
|
|
# define __compiletime_warning(message)
|
|
|
|
|
#endif
|
2009-10-02 22:50:50 +08:00
|
|
|
#ifndef __compiletime_error
|
|
|
|
|
# define __compiletime_error(message)
|
2014-06-05 07:11:16 +08:00
|
|
|
/*
|
|
|
|
|
* Sparse complains of variable sized arrays due to the temporary variable in
|
|
|
|
|
* __compiletime_assert. Unfortunately we can't just expand it out to make
|
|
|
|
|
* sparse see a constant array size without breaking compiletime_assert on old
|
|
|
|
|
* versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
|
|
|
|
|
*/
|
|
|
|
|
# ifndef __CHECKER__
|
|
|
|
|
# define __compiletime_error_fallback(condition) \
|
bug.h, compiler.h: introduce compiletime_assert & BUILD_BUG_ON_MSG
Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the
tradition of the POSIX assert macro, compiletime_assert creates a
build-time error when the supplied condition is *false*.
Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.
Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG. This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).
Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 08:41:55 +08:00
|
|
|
do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
|
2014-06-05 07:11:16 +08:00
|
|
|
# endif
|
|
|
|
|
#endif
|
|
|
|
|
#ifndef __compiletime_error_fallback
|
compiler.h, bug.h: prevent double error messages with BUILD_BUG{,_ON}
Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases. The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.
This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.
Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used. The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized. However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.
Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 08:41:54 +08:00
|
|
|
# define __compiletime_error_fallback(condition) do { } while (0)
|
2009-10-02 22:50:50 +08:00
|
|
|
#endif
|
compiler.h, bug.h: prevent double error messages with BUILD_BUG{,_ON}
Prior to the introduction of __attribute__((error("msg"))) in gcc 4.3,
creating compile-time errors required a little trickery.
BUILD_BUG{,_ON} uses this attribute when available to generate
compile-time errors, but also uses the negative-sized array trick for
older compilers, resulting in two error messages in some cases. The
reason it's "some" cases is that as of gcc 4.4, the negative-sized array
will not create an error in some situations, like inline functions.
This patch replaces the negative-sized array code with the new
__compiletime_error_fallback() macro which expands to the same thing
unless the the error attribute is available, in which case it expands to
do{}while(0), resulting in exactly one compile-time error on all
versions of gcc.
Note that we are not changing the negative-sized array code for the
unoptimized version of BUILD_BUG_ON, since it has the potential to catch
problems that would be disabled in later versions of gcc were
__compiletime_error_fallback used. The reason is that that an
unoptimized build can't always remove calls to an error-attributed
function call (like we are using) that should effectively become dead
code if it were optimized. However, using a negative-sized array with a
similar value will not result in an false-positive (error). The only
caveat being that it will also fail to catch valid conditions, which we
should be expecting in an unoptimized build anyway.
Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 08:41:54 +08:00
|
|
|
|
include/linux/compiler.h: don't perform compiletime_assert with -O0
Commit c7acec713d14 ("kernel.h: handle pointers to arrays better in
container_of()") made use of __compiletime_assert() from container_of()
thus increasing the usage of this macro, allowing developers to notice
type conflicts in usage of container_of() at compile time.
However, the implementation of __compiletime_assert relies on compiler
optimizations to report an error. This means that if a developer uses
"-O0" with any code that performs container_of(), the compiler will always
report an error regardless of whether there is an actual problem in the
code.
This patch disables compile_time_assert when optimizations are disabled to
allow such code to compile with CFLAGS="-O0".
Example compilation failure:
./include/linux/compiler.h:547:38: error: call to `__compiletime_assert_94' declared with attribute error: pointer type mismatch in container_of()
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
./include/linux/compiler.h:530:4: note: in definition of macro `__compiletime_assert'
prefix ## suffix(); \
^~~~~~
./include/linux/compiler.h:547:2: note: in expansion of macro `_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:46:37: note: in expansion of macro `compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
./include/linux/kernel.h:860:2: note: in expansion of macro `BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~~~~~~~~~~~~~
[akpm@linux-foundation.org: use do{}while(0), per Michal]
Link: http://lkml.kernel.org/r/20170829230114.11662-1-joe@ovn.org
Fixes: c7acec713d14c6c ("kernel.h: handle pointers to arrays better in container_of()")
Signed-off-by: Joe Stringer <joe@ovn.org>
Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-01 07:15:33 +08:00
|
|
|
#ifdef __OPTIMIZE__
|
|
|
|
|
# define __compiletime_assert(condition, msg, prefix, suffix) \
|
bug.h, compiler.h: introduce compiletime_assert & BUILD_BUG_ON_MSG
Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the
tradition of the POSIX assert macro, compiletime_assert creates a
build-time error when the supplied condition is *false*.
Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.
Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG. This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).
Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 08:41:55 +08:00
|
|
|
do { \
|
|
|
|
|
bool __cond = !(condition); \
|
|
|
|
|
extern void prefix ## suffix(void) __compiletime_error(msg); \
|
|
|
|
|
if (__cond) \
|
|
|
|
|
prefix ## suffix(); \
|
|
|
|
|
__compiletime_error_fallback(__cond); \
|
|
|
|
|
} while (0)
|
include/linux/compiler.h: don't perform compiletime_assert with -O0
Commit c7acec713d14 ("kernel.h: handle pointers to arrays better in
container_of()") made use of __compiletime_assert() from container_of()
thus increasing the usage of this macro, allowing developers to notice
type conflicts in usage of container_of() at compile time.
However, the implementation of __compiletime_assert relies on compiler
optimizations to report an error. This means that if a developer uses
"-O0" with any code that performs container_of(), the compiler will always
report an error regardless of whether there is an actual problem in the
code.
This patch disables compile_time_assert when optimizations are disabled to
allow such code to compile with CFLAGS="-O0".
Example compilation failure:
./include/linux/compiler.h:547:38: error: call to `__compiletime_assert_94' declared with attribute error: pointer type mismatch in container_of()
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
./include/linux/compiler.h:530:4: note: in definition of macro `__compiletime_assert'
prefix ## suffix(); \
^~~~~~
./include/linux/compiler.h:547:2: note: in expansion of macro `_compiletime_assert'
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:46:37: note: in expansion of macro `compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~~~~~~~~~~~~~~~~~
./include/linux/kernel.h:860:2: note: in expansion of macro `BUILD_BUG_ON_MSG'
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
^~~~~~~~~~~~~~~~
[akpm@linux-foundation.org: use do{}while(0), per Michal]
Link: http://lkml.kernel.org/r/20170829230114.11662-1-joe@ovn.org
Fixes: c7acec713d14c6c ("kernel.h: handle pointers to arrays better in container_of()")
Signed-off-by: Joe Stringer <joe@ovn.org>
Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-09-01 07:15:33 +08:00
|
|
|
#else
|
|
|
|
|
# define __compiletime_assert(condition, msg, prefix, suffix) do { } while (0)
|
|
|
|
|
#endif
|
bug.h, compiler.h: introduce compiletime_assert & BUILD_BUG_ON_MSG
Introduce compiletime_assert to compiler.h, which moves the details of
how to break a build and emit an error message for a specific compiler
to the headers where these details should be. Following in the
tradition of the POSIX assert macro, compiletime_assert creates a
build-time error when the supplied condition is *false*.
Next, we add BUILD_BUG_ON_MSG to bug.h which simply wraps
compiletime_assert, inverting the logic, so that it fails when the
condition is *true*, consistent with the language "build bug on." This
macro allows you to specify the error message you want emitted when the
supplied condition is true.
Finally, we remove all other code from bug.h that mucks with these
details (BUILD_BUG & BUILD_BUG_ON), and have them all call
BUILD_BUG_ON_MSG. This not only reduces source code bloat, but also
prevents the possibility of code being changed for one macro and not for
the other (which was previously the case for BUILD_BUG and
BUILD_BUG_ON).
Since __compiletime_error_fallback is now only used in compiler.h, I'm
considering it a private macro and removing the double negation that's
now extraneous.
[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: Daniel Santos <daniel.santos@pobox.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Rientjes <rientjes@google.com>
Cc: Joe Perches <joe@perches.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-22 08:41:55 +08:00
|
|
|
|
|
|
|
|
#define _compiletime_assert(condition, msg, prefix, suffix) \
|
|
|
|
|
__compiletime_assert(condition, msg, prefix, suffix)
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* compiletime_assert - break build and emit msg if condition is false
|
|
|
|
|
* @condition: a compile-time constant condition to check
|
|
|
|
|
* @msg: a message to emit if condition is false
|
|
|
|
|
*
|
|
|
|
|
* In tradition of POSIX assert, this macro will break the build if the
|
|
|
|
|
* supplied condition is *false*, emitting the supplied error message if the
|
|
|
|
|
* compiler has support to do so.
|
|
|
|
|
*/
|
|
|
|
|
#define compiletime_assert(condition, msg) \
|
|
|
|
|
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|
|
|
|
|
|
2013-11-06 21:57:36 +08:00
|
|
|
#define compiletime_assert_atomic_type(t) \
|
|
|
|
|
compiletime_assert(__native_word(t), \
|
|
|
|
|
"Need native word sized stores/loads for atomicity.")
|
|
|
|
|
|
2008-05-11 10:51:16 +08:00
|
|
|
/*
|
|
|
|
|
* Prevent the compiler from merging or refetching accesses. The compiler
|
|
|
|
|
* is also forbidden from reordering successive instances of ACCESS_ONCE(),
|
|
|
|
|
* but only when the compiler is aware of some particular ordering. One way
|
|
|
|
|
* to make the compiler aware of ordering is to put the two invocations of
|
|
|
|
|
* ACCESS_ONCE() in different C statements.
|
|
|
|
|
*
|
2014-11-25 17:16:39 +08:00
|
|
|
* ACCESS_ONCE will only work on scalar types. For union types, ACCESS_ONCE
|
|
|
|
|
* on a union member will work as long as the size of the member matches the
|
|
|
|
|
* size of the union and the size is smaller than word size.
|
|
|
|
|
*
|
|
|
|
|
* The major use cases of ACCESS_ONCE used to be (1) Mediating communication
|
|
|
|
|
* between process-level code and irq/NMI handlers, all running on the same CPU,
|
|
|
|
|
* and (2) Ensuring that the compiler does not fold, spindle, or otherwise
|
|
|
|
|
* mutilate accesses that either do not require ordering or that interact
|
|
|
|
|
* with an explicit memory barrier or atomic instruction that provides the
|
|
|
|
|
* required ordering.
|
|
|
|
|
*
|
2015-04-30 19:57:21 +08:00
|
|
|
* If possible use READ_ONCE()/WRITE_ONCE() instead.
|
2008-05-11 10:51:16 +08:00
|
|
|
*/
|
2014-11-25 17:16:39 +08:00
|
|
|
#define __ACCESS_ONCE(x) ({ \
|
2015-01-12 19:13:39 +08:00
|
|
|
__maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
|
2014-11-25 17:16:39 +08:00
|
|
|
(volatile typeof(x) *)&(x); })
|
|
|
|
|
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))
|
2008-05-11 10:51:16 +08:00
|
|
|
|
2015-05-27 09:39:36 +08:00
|
|
|
/**
|
|
|
|
|
* lockless_dereference() - safely load a pointer for later dereference
|
|
|
|
|
* @p: The pointer to load
|
|
|
|
|
*
|
|
|
|
|
* Similar to rcu_dereference(), but for situations where the pointed-to
|
|
|
|
|
* object's lifetime is managed by something other than RCU. That
|
|
|
|
|
* "something other" might be reference counting or simple immortality.
|
2016-05-22 18:48:27 +08:00
|
|
|
*
|
2016-08-26 14:16:00 +08:00
|
|
|
* The seemingly unused variable ___typecheck_p validates that @p is
|
|
|
|
|
* indeed a pointer type by using a pointer to typeof(*p) as the type.
|
|
|
|
|
* Taking a pointer to typeof(*p) again is needed in case p is void *.
|
2015-05-27 09:39:36 +08:00
|
|
|
*/
|
|
|
|
|
#define lockless_dereference(p) \
|
|
|
|
|
({ \
|
2015-05-28 15:20:58 +08:00
|
|
|
typeof(p) _________p1 = READ_ONCE(p); \
|
2016-08-26 14:16:00 +08:00
|
|
|
typeof(*(p)) *___typecheck_p __maybe_unused; \
|
2015-05-27 09:39:36 +08:00
|
|
|
smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
|
|
|
|
|
(_________p1); \
|
|
|
|
|
})
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* __LINUX_COMPILER_H */
|
