License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 15:07:57 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
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 12:22:46 +02:00
|
|
|
#ifndef __LINUX_COMPILER_TYPES_H
|
2007-10-17 08:26:11 +02:00
|
|
|
#error "Please don't include <linux/compiler-gcc.h> directly, include <linux/compiler.h> instead."
|
|
|
|
|
#endif
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Common definitions for all gcc versions go here.
|
|
|
|
|
*/
|
2015-06-26 00:01:00 +02:00
|
|
|
#define GCC_VERSION (__GNUC__ * 10000 \
|
|
|
|
|
+ __GNUC_MINOR__ * 100 \
|
|
|
|
|
+ __GNUC_PATCHLEVEL__)
|
2005-04-17 00:20:36 +02:00
|
|
|
|
|
|
|
|
/* Optimization barrier */
|
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 04:13:52 +02:00
|
|
|
|
2005-04-17 00:20:36 +02:00
|
|
|
/* The "volatile" is due to gcc bugs */
|
|
|
|
|
#define barrier() __asm__ __volatile__("": : :"memory")
|
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 04:13:52 +02:00
|
|
|
/*
|
|
|
|
|
* This version is i.e. to prevent dead stores elimination on @ptr
|
|
|
|
|
* where gcc and llvm may behave differently when otherwise using
|
|
|
|
|
* normal barrier(): while gcc behavior gets along with a normal
|
|
|
|
|
* barrier(), llvm needs an explicit input variable to be assumed
|
|
|
|
|
* clobbered. The issue is as follows: while the inline asm might
|
|
|
|
|
* access any memory it wants, the compiler could have fit all of
|
|
|
|
|
* @ptr into memory registers instead, and since @ptr never escaped
|
2016-12-13 01:45:38 +01:00
|
|
|
* from that, it proved that the inline asm wasn't touching any of
|
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 04:13:52 +02:00
|
|
|
* it. This version works well with both compilers, i.e. we're telling
|
|
|
|
|
* the compiler that the inline asm absolutely may see the contents
|
|
|
|
|
* of @ptr. See also: https://llvm.org/bugs/show_bug.cgi?id=15495
|
|
|
|
|
*/
|
|
|
|
|
#define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory")
|
2005-04-17 00:20:36 +02:00
|
|
|
|
2006-01-10 08:21:20 +01:00
|
|
|
/*
|
2009-01-10 01:40:53 +01:00
|
|
|
* This macro obfuscates arithmetic on a variable address so that gcc
|
|
|
|
|
* shouldn't recognize the original var, and make assumptions about it.
|
|
|
|
|
*
|
|
|
|
|
* This is needed because the C standard makes it undefined to do
|
|
|
|
|
* pointer arithmetic on "objects" outside their boundaries and the
|
|
|
|
|
* gcc optimizers assume this is the case. In particular they
|
|
|
|
|
* assume such arithmetic does not wrap.
|
|
|
|
|
*
|
|
|
|
|
* A miscompilation has been observed because of this on PPC.
|
|
|
|
|
* To work around it we hide the relationship of the pointer and the object
|
|
|
|
|
* using this macro.
|
|
|
|
|
*
|
2006-01-10 08:21:20 +01:00
|
|
|
* Versions of the ppc64 compiler before 4.1 had a bug where use of
|
|
|
|
|
* RELOC_HIDE could trash r30. The bug can be worked around by changing
|
|
|
|
|
* the inline assembly constraint from =g to =r, in this particular
|
|
|
|
|
* case either is valid.
|
|
|
|
|
*/
|
2015-06-26 00:01:00 +02:00
|
|
|
#define RELOC_HIDE(ptr, off) \
|
|
|
|
|
({ \
|
|
|
|
|
unsigned long __ptr; \
|
|
|
|
|
__asm__ ("" : "=r"(__ptr) : "0"(ptr)); \
|
|
|
|
|
(typeof(ptr)) (__ptr + (off)); \
|
|
|
|
|
})
|
2006-01-08 10:04:09 +01:00
|
|
|
|
2013-11-26 01:00:41 +01:00
|
|
|
/* Make the optimizer believe the variable can be manipulated arbitrarily. */
|
2015-06-26 00:01:00 +02:00
|
|
|
#define OPTIMIZER_HIDE_VAR(var) \
|
|
|
|
|
__asm__ ("" : "=r" (var) : "0" (var))
|
2013-11-26 01:00:41 +01:00
|
|
|
|
2011-05-25 02:13:17 +02:00
|
|
|
#ifdef __CHECKER__
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __must_be_array(a) 0
|
2011-05-25 02:13:17 +02:00
|
|
|
#else
|
2007-05-06 23:51:05 +02:00
|
|
|
/* &a[0] degrades to a pointer: a different type from an array */
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
|
2011-05-25 02:13:17 +02:00
|
|
|
#endif
|
2006-01-08 10:04:09 +01:00
|
|
|
|
2008-03-03 12:38:52 +01:00
|
|
|
/*
|
2008-04-30 00:15:31 +02:00
|
|
|
* Force always-inline if the user requests it so via the .config,
|
2017-07-07 00:35:24 +02:00
|
|
|
* or if gcc is too old.
|
|
|
|
|
* GCC does not warn about unused static inline functions for
|
|
|
|
|
* -Wunused-function. This turns out to avoid the need for complex #ifdef
|
|
|
|
|
* directives. Suppress the warning in clang as well by using "unused"
|
|
|
|
|
* function attribute, which is redundant but not harmful for gcc.
|
2008-03-03 12:38:52 +01:00
|
|
|
*/
|
2015-06-26 00:01:00 +02:00
|
|
|
#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
|
2008-04-30 00:15:31 +02:00
|
|
|
!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
|
2017-07-07 00:35:24 +02:00
|
|
|
#define inline inline __attribute__((always_inline,unused)) notrace
|
|
|
|
|
#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace
|
|
|
|
|
#define __inline __inline __attribute__((always_inline,unused)) notrace
|
ftrace: Do not function trace inlined functions
When gcc inlines a function, it does not mark it with the mcount
prologue, which in turn means that inlined functions are not traced
by the function tracer. But if CONFIG_OPTIMIZE_INLINING is set, then
gcc is allowed not to inline a function that is marked inline.
Depending on the options and the compiler, a function may or may
not be traced by the function tracer, depending on whether gcc
decides to inline a function or not. This has caused several
problems in the pass becaues gcc is not always consistent with
what it decides to inline between different gcc versions.
Some places should not be traced (like paravirt native_* functions)
and these are mostly marked as inline. When gcc decides not to
inline the function, and if that function should not be traced, then
the ftrace function tracer will suddenly break when it use to work
fine. This becomes even harder to debug when different versions of
gcc will not inline that function, making the same kernel and config
work for some gcc versions and not work for others.
By making all functions marked inline to not be traced will remove
the ambiguity that gcc adds when it comes to tracing functions marked
inline. All gcc versions will be consistent with what functions are
traced and having volatile working code will be removed.
Note, only the inline macro when CONFIG_OPTIMIZE_INLINING is set needs
to have notrace added, as the attribute __always_inline will force
the function to be inlined and then not traced.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2011-12-12 21:22:41 +01:00
|
|
|
#else
|
|
|
|
|
/* A lot of inline functions can cause havoc with function tracing */
|
2017-07-07 00:35:24 +02:00
|
|
|
#define inline inline __attribute__((unused)) notrace
|
|
|
|
|
#define __inline__ __inline__ __attribute__((unused)) notrace
|
|
|
|
|
#define __inline __inline __attribute__((unused)) notrace
|
2008-03-03 12:38:52 +01:00
|
|
|
#endif
|
|
|
|
|
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __always_inline inline __attribute__((always_inline))
|
|
|
|
|
#define noinline __attribute__((noinline))
|
|
|
|
|
|
|
|
|
|
#define __deprecated __attribute__((deprecated))
|
|
|
|
|
#define __packed __attribute__((packed))
|
|
|
|
|
#define __weak __attribute__((weak))
|
|
|
|
|
#define __alias(symbol) __attribute__((alias(#symbol)))
|
2009-03-12 18:03:16 +01:00
|
|
|
|
2018-02-19 11:50:57 +01:00
|
|
|
#ifdef RETPOLINE
|
|
|
|
|
#define __noretpoline __attribute__((indirect_branch("keep")))
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-03-12 18:03:16 +01:00
|
|
|
/*
|
2015-06-26 00:01:00 +02:00
|
|
|
* it doesn't make sense on ARM (currently the only user of __naked)
|
|
|
|
|
* to trace naked functions because then mcount is called without
|
|
|
|
|
* stack and frame pointer being set up and there is no chance to
|
|
|
|
|
* restore the lr register to the value before mcount was called.
|
|
|
|
|
*
|
|
|
|
|
* The asm() bodies of naked functions often depend on standard calling
|
|
|
|
|
* conventions, therefore they must be noinline and noclone.
|
2010-06-30 00:05:25 +02:00
|
|
|
*
|
2015-06-26 00:01:00 +02:00
|
|
|
* GCC 4.[56] currently fail to enforce this, so we must do so ourselves.
|
|
|
|
|
* See GCC PR44290.
|
2009-03-12 18:03:16 +01:00
|
|
|
*/
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __naked __attribute__((naked)) noinline __noclone notrace
|
2009-03-12 18:03:16 +01:00
|
|
|
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __noreturn __attribute__((noreturn))
|
2007-10-18 12:07:07 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* From the GCC manual:
|
|
|
|
|
*
|
|
|
|
|
* Many functions have no effects except the return value and their
|
|
|
|
|
* return value depends only on the parameters and/or global
|
|
|
|
|
* variables. Such a function can be subject to common subexpression
|
|
|
|
|
* elimination and loop optimization just as an arithmetic operator
|
|
|
|
|
* would be.
|
|
|
|
|
* [...]
|
|
|
|
|
*/
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __pure __attribute__((pure))
|
|
|
|
|
#define __aligned(x) __attribute__((aligned(x)))
|
2016-12-31 16:56:23 +01:00
|
|
|
#define __aligned_largest __attribute__((aligned))
|
2015-06-26 00:01:00 +02:00
|
|
|
#define __printf(a, b) __attribute__((format(printf, a, b)))
|
|
|
|
|
#define __scanf(a, b) __attribute__((format(scanf, a, b)))
|
|
|
|
|
#define __attribute_const__ __attribute__((__const__))
|
|
|
|
|
#define __maybe_unused __attribute__((unused))
|
|
|
|
|
#define __always_unused __attribute__((unused))
|
2017-02-25 00:00:32 +01:00
|
|
|
#define __mode(x) __attribute__((mode(x)))
|
2009-01-02 18:23:03 +01:00
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
/* gcc version specific checks */
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION < 30200
|
|
|
|
|
# error Sorry, your compiler is too old - please upgrade it.
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION < 30300
|
|
|
|
|
# define __used __attribute__((__unused__))
|
|
|
|
|
#else
|
|
|
|
|
# define __used __attribute__((__used__))
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_GCOV_KERNEL
|
|
|
|
|
# if GCC_VERSION < 30400
|
|
|
|
|
# error "GCOV profiling support for gcc versions below 3.4 not included"
|
|
|
|
|
# endif /* __GNUC_MINOR__ */
|
|
|
|
|
#endif /* CONFIG_GCOV_KERNEL */
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION >= 30400
|
|
|
|
|
#define __must_check __attribute__((warn_unused_result))
|
2016-05-20 02:10:52 +02:00
|
|
|
#define __malloc __attribute__((__malloc__))
|
2015-06-26 00:01:02 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION >= 40000
|
|
|
|
|
|
|
|
|
|
/* GCC 4.1.[01] miscompiles __weak */
|
|
|
|
|
#ifdef __KERNEL__
|
|
|
|
|
# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101
|
|
|
|
|
# error Your version of gcc miscompiles the __weak directive
|
|
|
|
|
# endif
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#define __used __attribute__((__used__))
|
|
|
|
|
#define __compiler_offsetof(a, b) \
|
|
|
|
|
__builtin_offsetof(a, b)
|
|
|
|
|
|
mm/usercopy: get rid of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
There are three usercopy warnings which are currently being silenced for
gcc 4.6 and newer:
1) "copy_from_user() buffer size is too small" compile warning/error
This is a static warning which happens when object size and copy size
are both const, and copy size > object size. I didn't see any false
positives for this one. So the function warning attribute seems to
be working fine here.
Note this scenario is always a bug and so I think it should be
changed to *always* be an error, regardless of
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS.
2) "copy_from_user() buffer size is not provably correct" compile warning
This is another static warning which happens when I enable
__compiletime_object_size() for new compilers (and
CONFIG_DEBUG_STRICT_USER_COPY_CHECKS). It happens when object size
is const, but copy size is *not*. In this case there's no way to
compare the two at build time, so it gives the warning. (Note the
warning is a byproduct of the fact that gcc has no way of knowing
whether the overflow function will be called, so the call isn't dead
code and the warning attribute is activated.)
So this warning seems to only indicate "this is an unusual pattern,
maybe you should check it out" rather than "this is a bug".
I get 102(!) of these warnings with allyesconfig and the
__compiletime_object_size() gcc check removed. I don't know if there
are any real bugs hiding in there, but from looking at a small
sample, I didn't see any. According to Kees, it does sometimes find
real bugs. But the false positive rate seems high.
3) "Buffer overflow detected" runtime warning
This is a runtime warning where object size is const, and copy size >
object size.
All three warnings (both static and runtime) were completely disabled
for gcc 4.6 with the following commit:
2fb0815c9ee6 ("gcc4: disable __compiletime_object_size for GCC 4.6+")
That commit mistakenly assumed that the false positives were caused by a
gcc bug in __compiletime_object_size(). But in fact,
__compiletime_object_size() seems to be working fine. The false
positives were instead triggered by #2 above. (Though I don't have an
explanation for why the warnings supposedly only started showing up in
gcc 4.6.)
So remove warning #2 to get rid of all the false positives, and re-enable
warnings #1 and #3 by reverting the above commit.
Furthermore, since #1 is a real bug which is detected at compile time,
upgrade it to always be an error.
Having done all that, CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is no longer
needed.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "H . Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Nilay Vaish <nilayvaish@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-08-30 15:04:16 +02:00
|
|
|
#if GCC_VERSION >= 40100
|
2015-06-26 00:01:02 +02:00
|
|
|
# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION >= 40300
|
|
|
|
|
/* Mark functions as cold. gcc will assume any path leading to a call
|
|
|
|
|
* to them will be unlikely. This means a lot of manual unlikely()s
|
|
|
|
|
* are unnecessary now for any paths leading to the usual suspects
|
|
|
|
|
* like BUG(), printk(), panic() etc. [but let's keep them for now for
|
|
|
|
|
* older compilers]
|
|
|
|
|
*
|
|
|
|
|
* Early snapshots of gcc 4.3 don't support this and we can't detect this
|
|
|
|
|
* in the preprocessor, but we can live with this because they're unreleased.
|
|
|
|
|
* Maketime probing would be overkill here.
|
|
|
|
|
*
|
|
|
|
|
* gcc also has a __attribute__((__hot__)) to move hot functions into
|
|
|
|
|
* a special section, but I don't see any sense in this right now in
|
|
|
|
|
* the kernel context
|
|
|
|
|
*/
|
|
|
|
|
#define __cold __attribute__((__cold__))
|
|
|
|
|
|
|
|
|
|
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
|
|
|
|
|
|
|
|
|
|
#ifndef __CHECKER__
|
|
|
|
|
# define __compiletime_warning(message) __attribute__((warning(message)))
|
|
|
|
|
# define __compiletime_error(message) __attribute__((error(message)))
|
|
|
|
|
#endif /* __CHECKER__ */
|
|
|
|
|
#endif /* GCC_VERSION >= 40300 */
|
|
|
|
|
|
2018-02-01 11:21:58 +01:00
|
|
|
#if GCC_VERSION >= 40400
|
|
|
|
|
#define __optimize(level) __attribute__((__optimize__(level)))
|
2018-02-01 11:21:59 +01:00
|
|
|
#define __nostackprotector __optimize("no-stack-protector")
|
2018-02-01 11:21:58 +01:00
|
|
|
#endif /* GCC_VERSION >= 40400 */
|
|
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
#if GCC_VERSION >= 40500
|
2016-06-20 20:42:34 +02:00
|
|
|
|
|
|
|
|
#ifndef __CHECKER__
|
|
|
|
|
#ifdef LATENT_ENTROPY_PLUGIN
|
|
|
|
|
#define __latent_entropy __attribute__((latent_entropy))
|
|
|
|
|
#endif
|
|
|
|
|
#endif
|
|
|
|
|
|
bug.h: work around GCC PR82365 in BUG()
Looking at functions with large stack frames across all architectures
led me discovering that BUG() suffers from the same problem as
fortify_panic(), which I've added a workaround for already.
In short, variables that go out of scope by calling a noreturn function
or __builtin_unreachable() keep using stack space in functions
afterwards.
A workaround that was identified is to insert an empty assembler
statement just before calling the function that doesn't return. I'm
adding a macro "barrier_before_unreachable()" to document this, and
insert calls to that in all instances of BUG() that currently suffer
from this problem.
The files that saw the largest change from this had these frame sizes
before, and much less with my patch:
fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=]
drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=]
In case of ARC and CRIS, it turns out that the BUG() implementation
actually does return (or at least the compiler thinks it does),
resulting in lots of warnings about uninitialized variable use and
leaving noreturn functions, such as:
block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type]
include/linux/dmaengine.h: In function 'dma_maxpq':
include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type]
This makes them call __builtin_trap() instead, which should normally
dump the stack and kill the current process, like some of the other
architectures already do.
I tried adding barrier_before_unreachable() to panic() and
fortify_panic() as well, but that had very little effect, so I'm not
submitting that patch.
Vineet said:
: For ARC, it is double win.
:
: 1. Fixes 3 -Wreturn-type warnings
:
: | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of
: non-void function [-Wreturn-type]
:
: 2. bloat-o-meter reports code size improvements as gcc elides the
: generated code for stack return.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vineet Gupta <vgupta@synopsys.com> [arch/arc]
Tested-by: Vineet Gupta <vgupta@synopsys.com> [arch/arc]
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Christopher Li <sparse@chrisli.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-21 23:45:54 +01:00
|
|
|
/*
|
|
|
|
|
* calling noreturn functions, __builtin_unreachable() and __builtin_trap()
|
|
|
|
|
* confuse the stack allocation in gcc, leading to overly large stack
|
|
|
|
|
* frames, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
|
|
|
|
|
*
|
|
|
|
|
* Adding an empty inline assembly before it works around the problem
|
|
|
|
|
*/
|
|
|
|
|
#define barrier_before_unreachable() asm volatile("")
|
|
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
/*
|
|
|
|
|
* Mark a position in code as unreachable. This can be used to
|
|
|
|
|
* suppress control flow warnings after asm blocks that transfer
|
|
|
|
|
* control elsewhere.
|
|
|
|
|
*
|
|
|
|
|
* Early snapshots of gcc 4.5 don't support this and we can't detect
|
|
|
|
|
* this in the preprocessor, but we can live with this because they're
|
|
|
|
|
* unreleased. Really, we need to have autoconf for the kernel.
|
|
|
|
|
*/
|
2017-02-28 05:21:16 +01:00
|
|
|
#define unreachable() \
|
bug.h: work around GCC PR82365 in BUG()
Looking at functions with large stack frames across all architectures
led me discovering that BUG() suffers from the same problem as
fortify_panic(), which I've added a workaround for already.
In short, variables that go out of scope by calling a noreturn function
or __builtin_unreachable() keep using stack space in functions
afterwards.
A workaround that was identified is to insert an empty assembler
statement just before calling the function that doesn't return. I'm
adding a macro "barrier_before_unreachable()" to document this, and
insert calls to that in all instances of BUG() that currently suffer
from this problem.
The files that saw the largest change from this had these frame sizes
before, and much less with my patch:
fs/ext4/inode.c:82:1: warning: the frame size of 1672 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/namei.c:434:1: warning: the frame size of 904 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/super.c:2279:1: warning: the frame size of 1160 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/ext4/xattr.c:146:1: warning: the frame size of 1168 bytes is larger than 800 bytes [-Wframe-larger-than=]
fs/f2fs/inode.c:152:1: warning: the frame size of 1424 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:1195:1: warning: the frame size of 1068 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_core.c:395:1: warning: the frame size of 1084 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:298:1: warning: the frame size of 928 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_ftp.c:418:1: warning: the frame size of 908 bytes is larger than 800 bytes [-Wframe-larger-than=]
net/netfilter/ipvs/ip_vs_lblcr.c:718:1: warning: the frame size of 960 bytes is larger than 800 bytes [-Wframe-larger-than=]
drivers/net/xen-netback/netback.c:1500:1: warning: the frame size of 1088 bytes is larger than 800 bytes [-Wframe-larger-than=]
In case of ARC and CRIS, it turns out that the BUG() implementation
actually does return (or at least the compiler thinks it does),
resulting in lots of warnings about uninitialized variable use and
leaving noreturn functions, such as:
block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:3804:1: error: control reaches end of non-void function [-Werror=return-type]
include/linux/dmaengine.h: In function 'dma_maxpq':
include/linux/dmaengine.h:1123:1: error: control reaches end of non-void function [-Werror=return-type]
This makes them call __builtin_trap() instead, which should normally
dump the stack and kill the current process, like some of the other
architectures already do.
I tried adding barrier_before_unreachable() to panic() and
fortify_panic() as well, but that had very little effect, so I'm not
submitting that patch.
Vineet said:
: For ARC, it is double win.
:
: 1. Fixes 3 -Wreturn-type warnings
:
: | ../net/core/ethtool.c:311:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../kernel/sched/core.c:3246:1: warning: control reaches end of non-void function
: [-Wreturn-type]
: | ../include/linux/sunrpc/svc_xprt.h:180:1: warning: control reaches end of
: non-void function [-Wreturn-type]
:
: 2. bloat-o-meter reports code size improvements as gcc elides the
: generated code for stack return.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
Link: http://lkml.kernel.org/r/20171219114112.939391-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vineet Gupta <vgupta@synopsys.com> [arch/arc]
Tested-by: Vineet Gupta <vgupta@synopsys.com> [arch/arc]
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Christopher Li <sparse@chrisli.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-21 23:45:54 +01:00
|
|
|
do { \
|
|
|
|
|
annotate_unreachable(); \
|
|
|
|
|
barrier_before_unreachable(); \
|
|
|
|
|
__builtin_unreachable(); \
|
|
|
|
|
} while (0)
|
2015-06-26 00:01:02 +02:00
|
|
|
|
|
|
|
|
/* Mark a function definition as prohibited from being cloned. */
|
2016-03-31 09:38:51 +02:00
|
|
|
#define __noclone __attribute__((__noclone__, __optimize__("no-tracer")))
|
2015-06-26 00:01:02 +02:00
|
|
|
|
2018-01-19 01:34:08 +01:00
|
|
|
#if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
|
2017-05-06 08:37:45 +02:00
|
|
|
#define __randomize_layout __attribute__((randomize_layout))
|
|
|
|
|
#define __no_randomize_layout __attribute__((no_randomize_layout))
|
2018-04-11 01:32:44 +02:00
|
|
|
/* This anon struct can add padding, so only enable it under randstruct. */
|
|
|
|
|
#define randomized_struct_fields_start struct {
|
|
|
|
|
#define randomized_struct_fields_end } __randomize_layout;
|
2017-05-06 08:37:45 +02:00
|
|
|
#endif
|
|
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
#endif /* GCC_VERSION >= 40500 */
|
|
|
|
|
|
|
|
|
|
#if GCC_VERSION >= 40600
|
2017-04-06 07:43:33 +02:00
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
/*
|
2015-11-07 01:30:09 +01:00
|
|
|
* When used with Link Time Optimization, gcc can optimize away C functions or
|
|
|
|
|
* variables which are referenced only from assembly code. __visible tells the
|
|
|
|
|
* optimizer that something else uses this function or variable, thus preventing
|
|
|
|
|
* this.
|
2015-06-26 00:01:02 +02:00
|
|
|
*/
|
|
|
|
|
#define __visible __attribute__((externally_visible))
|
2017-04-06 07:43:33 +02:00
|
|
|
|
|
|
|
|
#endif /* GCC_VERSION >= 40600 */
|
2015-06-26 00:01:02 +02:00
|
|
|
|
2015-11-06 03:45:02 +01:00
|
|
|
|
2015-11-06 03:45:05 +01:00
|
|
|
#if GCC_VERSION >= 40900 && !defined(__CHECKER__)
|
2015-11-06 03:45:02 +01:00
|
|
|
/*
|
|
|
|
|
* __assume_aligned(n, k): Tell the optimizer that the returned
|
|
|
|
|
* pointer can be assumed to be k modulo n. The second argument is
|
|
|
|
|
* optional (default 0), so we use a variadic macro to make the
|
|
|
|
|
* shorthand.
|
|
|
|
|
*
|
|
|
|
|
* Beware: Do not apply this to functions which may return
|
|
|
|
|
* ERR_PTRs. Also, it is probably unwise to apply it to functions
|
|
|
|
|
* returning extra information in the low bits (but in that case the
|
|
|
|
|
* compiler should see some alignment anyway, when the return value is
|
|
|
|
|
* massaged by 'flags = ptr & 3; ptr &= ~3;').
|
|
|
|
|
*/
|
|
|
|
|
#define __assume_aligned(a, ...) __attribute__((__assume_aligned__(a, ## __VA_ARGS__)))
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
/*
|
|
|
|
|
* GCC 'asm goto' miscompiles certain code sequences:
|
|
|
|
|
*
|
|
|
|
|
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
|
|
|
|
|
*
|
|
|
|
|
* Work it around via a compiler barrier quirk suggested by Jakub Jelinek.
|
|
|
|
|
*
|
|
|
|
|
* (asm goto is automatically volatile - the naming reflects this.)
|
|
|
|
|
*/
|
|
|
|
|
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
|
|
|
|
|
|
2016-08-26 00:16:45 +02:00
|
|
|
/*
|
|
|
|
|
* sparse (__CHECKER__) pretends to be gcc, but can't do constant
|
|
|
|
|
* folding in __builtin_bswap*() (yet), so don't set these for it.
|
|
|
|
|
*/
|
|
|
|
|
#if defined(CONFIG_ARCH_USE_BUILTIN_BSWAP) && !defined(__CHECKER__)
|
2015-06-26 00:01:02 +02:00
|
|
|
#if GCC_VERSION >= 40400
|
|
|
|
|
#define __HAVE_BUILTIN_BSWAP32__
|
|
|
|
|
#define __HAVE_BUILTIN_BSWAP64__
|
|
|
|
|
#endif
|
2016-05-06 16:22:25 +02:00
|
|
|
#if GCC_VERSION >= 40800
|
2015-06-26 00:01:02 +02:00
|
|
|
#define __HAVE_BUILTIN_BSWAP16__
|
|
|
|
|
#endif
|
2016-08-26 00:16:45 +02:00
|
|
|
#endif /* CONFIG_ARCH_USE_BUILTIN_BSWAP && !__CHECKER__ */
|
2015-06-26 00:01:02 +02:00
|
|
|
|
2016-12-01 00:54:13 +01:00
|
|
|
#if GCC_VERSION >= 70000
|
|
|
|
|
#define KASAN_ABI_VERSION 5
|
|
|
|
|
#elif GCC_VERSION >= 50000
|
2015-06-26 00:01:02 +02:00
|
|
|
#define KASAN_ABI_VERSION 4
|
|
|
|
|
#elif GCC_VERSION >= 40902
|
|
|
|
|
#define KASAN_ABI_VERSION 3
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-10-19 10:37:17 +02:00
|
|
|
#if GCC_VERSION >= 40902
|
|
|
|
|
/*
|
|
|
|
|
* Tell the compiler that address safety instrumentation (KASAN)
|
|
|
|
|
* should not be applied to that function.
|
|
|
|
|
* Conflicts with inlining: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
|
|
|
|
|
*/
|
|
|
|
|
#define __no_sanitize_address __attribute__((no_sanitize_address))
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-04-05 18:49:19 +02:00
|
|
|
#if GCC_VERSION >= 50100
|
|
|
|
|
/*
|
|
|
|
|
* Mark structures as requiring designated initializers.
|
|
|
|
|
* https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
|
|
|
|
|
*/
|
|
|
|
|
#define __designated_init __attribute__((designated_init))
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-06-26 00:01:02 +02:00
|
|
|
#endif /* gcc version >= 40000 specific checks */
|
2010-06-30 00:05:25 +02:00
|
|
|
|
|
|
|
|
#if !defined(__noclone)
|
|
|
|
|
#define __noclone /* not needed */
|
|
|
|
|
#endif
|
2011-03-23 00:33:55 +01:00
|
|
|
|
2015-10-19 10:37:17 +02:00
|
|
|
#if !defined(__no_sanitize_address)
|
|
|
|
|
#define __no_sanitize_address
|
|
|
|
|
#endif
|
|
|
|
|
|
2011-03-23 00:33:55 +01:00
|
|
|
/*
|
|
|
|
|
* A trick to suppress uninitialized variable warning without generating any
|
|
|
|
|
* code
|
|
|
|
|
*/
|
|
|
|
|
#define uninitialized_var(x) x = x
|
compiler.h: enable builtin overflow checkers and add fallback code
This adds wrappers for the __builtin overflow checkers present in gcc
5.1+ as well as fallback implementations for earlier compilers. It's not
that easy to implement the fully generic __builtin_X_overflow(T1 a, T2
b, T3 *d) in macros, so the fallback code assumes that T1, T2 and T3 are
the same. We obviously don't want the wrappers to have different
semantics depending on $GCC_VERSION, so we also insist on that even when
using the builtins.
There are a few problems with the 'a+b < a' idiom for checking for
overflow: For signed types, it relies on undefined behaviour and is
not actually complete (it doesn't check underflow;
e.g. INT_MIN+INT_MIN == 0 isn't caught). Due to type promotion it
is wrong for all types (signed and unsigned) narrower than
int. Similarly, when a and b does not have the same type, there are
subtle cases like
u32 a;
if (a + sizeof(foo) < a)
return -EOVERFLOW;
a += sizeof(foo);
where the test is always false on 64 bit platforms. Add to that that it
is not always possible to determine the types involved at a glance.
The new overflow.h is somewhat bulky, but that's mostly a result of
trying to be type-generic, complete (e.g. catching not only overflow
but also signed underflow) and not relying on undefined behaviour.
Linus is of course right [1] that for unsigned subtraction a-b, the
right way to check for overflow (underflow) is "b > a" and not
"__builtin_sub_overflow(a, b, &d)", but that's just one out of six cases
covered here, and included mostly for completeness.
So is it worth it? I think it is, if nothing else for the documentation
value of seeing
if (check_add_overflow(a, b, &d))
return -EGOAWAY;
do_stuff_with(d);
instead of the open-coded (and possibly wrong and/or incomplete and/or
UBsan-tickling)
if (a+b < a)
return -EGOAWAY;
do_stuff_with(a+b);
While gcc does recognize the 'a+b < a' idiom for testing unsigned add
overflow, it doesn't do nearly as good for unsigned multiplication
(there's also no single well-established idiom). So using
check_mul_overflow in kcalloc and friends may also make gcc generate
slightly better code.
[1] https://lkml.org/lkml/2015/11/2/658
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-08 00:36:27 +02:00
|
|
|
|
|
|
|
|
#if GCC_VERSION >= 50100
|
|
|
|
|
#define COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW 1
|
|
|
|
|
#endif
|
