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
|
|
|
|
Linux 4.0-rc1
.. after extensive statistical analysis of my G+ polling, I've come to
the inescapable conclusion that internet polls are bad.
Big surprise.
But "Hurr durr I'ma sheep" trounced "I like online polls" by a 62-to-38%
margin, in a poll that people weren't even supposed to participate in.
Who can argue with solid numbers like that? 5,796 votes from people who
can't even follow the most basic directions?
In contrast, "v4.0" beat out "v3.20" by a slimmer margin of 56-to-44%,
but with a total of 29,110 votes right now.
Now, arguably, that vote spread is only about 3,200 votes, which is less
than the almost six thousand votes that the "please ignore" poll got, so
it could be considered noise.
But hey, I asked, so I'll honor the votes.
2015-02-22 18:21:14 -08:00
|
|
|
|
2018-02-11 15:04:29 -08:00
|
|
|
|
2011-05-29 17:43:36 -07:00
|
|
|
|
2018-03-25 12:44:30 -10:00
|
|
|
|
2017-01-29 14:25:17 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-04 12:56:05 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 20:43:36 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-12-17 06:56:11 -08:00
|
|
|
|
2009-12-17 15:51:37 -08:00
|
|
|
|
2009-12-17 06:56:11 -08:00
|
|
|
|
|
|
|
|
|
2010-01-08 12:25:37 +01:00
|
|
|
|
2009-12-17 06:56:11 -08:00
|
|
|
|
2013-11-11 15:27:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-04 14:29:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-26 16:03:07 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-04 14:29:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-19 20:42:30 +09:00
|
|
|
|
2014-07-04 14:29:30 +02:00
|
|
|
|
2017-01-18 22:16:55 -06:00
|
|
|
|
2014-07-04 14:29:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-30 10:45:43 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-05-26 16:03:07 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-12-06 22:20:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-02 21:38:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-02 17:07:28 +09:00
|
|
|
|
2017-11-05 10:44:16 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-03-31 16:41:36 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-09-21 18:09:02 -05:00
|
|
|
|
|
|
|
|
|
2007-12-06 22:20:11 +01:00
|
|
|
|
2012-10-15 13:49:12 +01:00
|
|
|
|
2007-09-21 18:09:02 -05:00
|
|
|
|
2017-06-30 10:45:43 +08:00
|
|
|
|
2016-03-13 09:13:55 +09:00
|
|
|
|
2014-09-09 20:02:23 +09:00
|
|
|
|
2014-09-09 20:02:24 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-09 20:02:22 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-09 20:02:24 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-24 17:03:17 +08:00
|
|
|
|
|
|
|
|
|
2014-09-09 20:02:24 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-25 23:25:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-04 12:56:06 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-25 17:29:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-02-19 13:50:37 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-19 03:40:26 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-10-04 12:56:06 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 16:26:18 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-12-20 21:51:55 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-11-11 14:27:32 -08:00
|
|
|
|
2007-11-02 12:22:47 +09:00
|
|
|
|
2017-07-10 18:08:08 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-21 16:24:06 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-10-11 23:22:58 +02:00
|
|
|
|
2009-12-21 16:24:06 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-10-11 11:11:36 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-11-12 20:14:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-25 19:42:04 +02:00
|
|
|
|
2008-12-02 23:17:12 -08:00
|
|
|
|
2010-10-25 05:48:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-27 23:00:59 +02:00
|
|
|
|
2008-12-02 23:17:12 -08:00
|
|
|
|
2008-07-27 23:00:59 +02:00
|
|
|
|
2008-06-21 00:24:17 +02:00
|
|
|
|
2009-04-11 08:39:27 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-04 14:38:26 -04:00
|
|
|
|
2011-05-25 15:24:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-04 14:38:26 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:51 -07:00
|
|
|
|
2010-12-14 11:39:44 -05:00
|
|
|
|
2006-06-08 22:12:51 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-07-09 20:02:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
|
|
|
|
|
2017-07-09 20:02:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-10 01:02:28 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-07-20 21:37:11 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-07-18 13:40:11 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-12-27 22:38:44 +01:00
|
|
|
|
2018-02-15 22:07:50 +01:00
|
|
|
|
2016-06-07 11:57:02 +02:00
|
|
|
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 17:33:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2016-06-07 11:57:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-02 18:01:26 +01:00
|
|
|
|
|
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
|
|
|
|
|
2012-10-02 18:01:26 +01:00
|
|
|
|
2016-06-15 17:45:45 +02:00
|
|
|
|
2012-10-02 18:01:26 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-02 18:01:26 +01:00
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
|
|
|
|
|
2012-10-02 18:01:26 +01:00
|
|
|
|
2017-06-06 16:15:28 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-10-12 18:22:25 +09:00
|
|
|
|
2007-10-14 22:21:35 +02:00
|
|
|
|
2017-07-26 15:36:23 +02:00
|
|
|
|
2009-06-15 08:54:02 +03:00
|
|
|
|
2014-10-20 12:23:12 +03:00
|
|
|
|
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-10-12 18:22:25 +09:00
|
|
|
|
|
|
|
|
|
2010-07-28 19:11:27 +02:00
|
|
|
|
|
|
|
|
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 17:33:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-10-12 18:22:25 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-11-17 15:37:31 +01:00
|
|
|
|
2017-07-09 20:02:36 +02:00
|
|
|
|
2017-12-10 01:02:28 +09:00
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-15 22:17:25 +02:00
|
|
|
|
2018-02-06 15:36:00 -08:00
|
|
|
|
|
|
|
|
|
2007-10-15 21:59:31 +02:00
|
|
|
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 17:33:09 +02:00
|
|
|
|
2010-07-28 19:11:27 +02:00
|
|
|
|
2011-04-20 13:45:30 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 07:51:42 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-16 22:49:15 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 10:31:06 +08:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2009-11-17 10:48:25 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-06 11:47:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2006-05-02 12:33:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-05-02 12:33:20 +02:00
|
|
|
|
2009-01-10 04:56:13 +01:00
|
|
|
|
2006-05-02 12:33:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-11-07 11:46:13 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 09:46:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 20:43:36 +09:00
|
|
|
|
2008-08-25 04:51:27 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-12-13 23:00:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-04 12:56:06 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2013-04-09 19:57:00 +02:00
|
|
|
|
2016-05-24 00:09:38 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-16 11:01:16 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-22 16:47:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-07 21:01:36 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-08-07 21:01:36 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:51 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-02-13 08:58:20 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-07 16:38:33 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-18 21:09:09 -07:00
|
|
|
|
2009-10-18 00:49:24 +02:00
|
|
|
|
2006-08-07 21:01:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-18 00:49:24 +02:00
|
|
|
|
2012-07-07 23:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-08-07 21:01:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:39 -07:00
|
|
|
|
2006-08-07 21:01:36 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-12-02 15:11:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-03 10:54:58 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-10-12 18:22:25 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-16 18:23:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 20:43:36 +09:00
|
|
|
|
Makefile: Fix unrecognized cross-compiler command line options
On architectures that setup CROSS_COMPILE in their arch/*/Makefile
(arc, blackfin, m68k, mips, parisc, score, sh, tile, unicore32, xtensa),
cc-option and cc-disable-warning may check against the wrong compiler,
causing errors like
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
if the host gcc supports a compiler option, while the cross compiler
doesn't support that option.
Move all logic using cc-option or cc-disable-warning below the inclusion
of the arch's Makefile to fix this.
Introduced by
- commit e74fc973b6e531fef1fce8b101ffff05ecfb774c ("Turn off
-Wmaybe-uninitialized when building with -Os"),
- commit 61163efae02040f66a95c8ed17f4407951ba58fa ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").
As -Wno-maybe-uninitialized requires a quite recent gcc (gcc 4.6.3 on
Ubuntu 12.04 LTS doesn't support it), this only showed up recently (gcc
4.8.2 on Ubuntu 14.04 LTS does support it).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-05-27 09:54:12 +02:00
|
|
|
|
|
|
|
|
|
2016-10-12 10:23:41 -07:00
|
|
|
|
2017-07-12 19:25:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefile: Fix unrecognized cross-compiler command line options
On architectures that setup CROSS_COMPILE in their arch/*/Makefile
(arc, blackfin, m68k, mips, parisc, score, sh, tile, unicore32, xtensa),
cc-option and cc-disable-warning may check against the wrong compiler,
causing errors like
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
if the host gcc supports a compiler option, while the cross compiler
doesn't support that option.
Move all logic using cc-option or cc-disable-warning below the inclusion
of the arch's Makefile to fix this.
Introduced by
- commit e74fc973b6e531fef1fce8b101ffff05ecfb774c ("Turn off
-Wmaybe-uninitialized when building with -Os"),
- commit 61163efae02040f66a95c8ed17f4407951ba58fa ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").
As -Wno-maybe-uninitialized requires a quite recent gcc (gcc 4.6.3 on
Ubuntu 12.04 LTS doesn't support it), this only showed up recently (gcc
4.8.2 on Ubuntu 14.04 LTS does support it).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-05-27 09:54:12 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-03-27 18:19:09 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-25 17:35:28 +02:00
|
|
|
|
Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.
This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-10 17:44:44 +01:00
|
|
|
|
2016-04-25 17:35:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.
This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-10 17:44:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
./Makefile: tell gcc optimizer to never introduce new data races
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load
into a non-conditional one, and that broke correctness (the condition
was met only if lock was held) and corrupted memory.
This particular problem with that particular code did not happen when
never gccs were used. I've brought this up with our gcc folks, as I
wanted to make sure that this can't really happen again, and it turns
out it actually can.
Quoting Martin Jambor <mjambor@suse.cz>:
"More current GCCs are more careful when it comes to replacing a
conditional load with a non-conditional one, most notably they check
that a store happens in each iteration of _a_ loop but they assume
loops are executed. They also perform a simple check whether the
store cannot trap which currently passes only for non-const
variables. A simple testcase demonstrating it on an x86_64 is for
example the following:
$ cat cond_store.c
int g_1 = 1;
int g_2[1024] __attribute__((section ("safe_section"), aligned (4096)));
int c = 4;
int __attribute__ ((noinline))
foo (void)
{
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])
;
}
return 2;
}
int main (int argc, char* argv[])
{
if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)
{
int e = errno;
error (e, e, "mprotect error %i", e);
}
foo ();
__builtin_printf("OK\n");
return 0;
}
/* EOF */
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
$ ./a.out
OK
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1
$ ./a.out
Segmentation fault
The testcase fails the same at least with 4.9, 4.8 and 4.7. Therefore
I would suggest building kernels with this parameter set to zero. I
also agree with Jikos that the default should be changed for -O2. I
have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII
failed, at -O2, not sure why) compiled with and without this option
and did not see any real difference between respective run-times"
Hopefully the default will be changed in newer gccs, but let's force it
for kernel builds so that we are on a safe side even when older gcc are
used.
The code in question was out-of-tree printk-in-NMI (yeah, surprise
suprise, once again) patch written by Petr Mladek, let me quote his
comment from our internal bugzilla:
"I have spent few days investigating inconsistent state of kernel ring buffer.
It went out that it was caused by speculative store generated by
gcc-4.3.4.
The problem is in assembly generated for make_free_space(). The functions is
called the following way:
+ vprintk_emit();
+ log = MAIN_LOG; // with logbuf_lock
or
log = NMI_LOG; // with nmi_logbuf_lock
cont_add(log, ...);
+ cont_flush(log, ...);
+ log_store(log, ...);
+ log_make_free_space(log, ...);
If called with log = NMI_LOG then only nmi_log_* global variables are safe to
modify but the generated code does store also into (main_)log_* global
variables:
<log_make_free_space>:
55 push %rbp
89 f6 mov %esi,%esi
48 8b 05 03 99 51 01 mov 0x1519903(%rip),%rax # ffffffff82620868 <nmi_log_next_id>
44 8b 1d ec 98 51 01 mov 0x15198ec(%rip),%r11d # ffffffff82620858 <log_next_idx>
8b 35 36 60 14 01 mov 0x1146036(%rip),%esi # ffffffff8224cfa8 <log_buf_len>
44 8b 35 33 60 14 01 mov 0x1146033(%rip),%r14d # ffffffff8224cfac <nmi_log_buf_len>
4c 8b 2d d0 98 51 01 mov 0x15198d0(%rip),%r13 # ffffffff82620850 <log_next_seq>
4c 8b 25 11 61 14 01 mov 0x1146111(%rip),%r12 # ffffffff8224d098 <log_buf>
49 89 c2 mov %rax,%r10
48 21 c2 and %rax,%rdx
48 8b 1d 0c 99 55 01 mov 0x155990c(%rip),%rbx # ffffffff826608a0 <nmi_log_buf>
49 c1 ea 20 shr $0x20,%r10
48 89 55 d0 mov %rdx,-0x30(%rbp)
44 29 de sub %r11d,%esi
45 29 d6 sub %r10d,%r14d
4c 8b 0d 97 98 51 01 mov 0x1519897(%rip),%r9 # ffffffff82620840 <log_first_seq>
eb 7e jmp ffffffff81107029 <log_make_free_space+0xe9>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 e8 mov %r13,%rax
4c 89 ca mov %r9,%rdx
74 0a je ffffffff8110703d <log_make_free_space+0xfd>
8b 15 27 98 51 01 mov 0x1519827(%rip),%edx # ffffffff82620860 <nmi_log_first_id>
48 8b 45 d0 mov -0x30(%rbp),%rax
48 39 c2 cmp %rax,%rdx # end of loop
0f 84 da 00 00 00 je ffffffff81107120 <log_make_free_space+0x1e0>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 0d 17 97 51 01 mov %r9,0x1519717(%rip) # ffffffff82620840 <log_first_seq>
^^^^^^^^^^^^^^^^^^^^^^^^^^
KABOOOM
74 35 je ffffffff81107160 <log_make_free_space+0x220>
It stores log_first_seq when edi == NMI_LOG. This instructions are used also
when edi == MAIN_LOG but the store is done speculatively before the condition
is decided. It is unsafe because we do not have "logbuf_lock" in NMI context
and some other process migh modify "log_first_seq" in parallel"
I believe that the best course of action is both
- building kernel (and anything multi-threaded, I guess) with that
optimization turned off
- persuade gcc folks to change the default for future releases
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marek Polacek <polacek@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Steven Noonan <steven@uplinklabs.net>
Cc: Richard Biener <richard.guenther@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-06 16:08:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-20 20:15:53 +03:00
|
|
|
|
2017-10-16 10:12:46 -07:00
|
|
|
|
2017-03-20 20:15:53 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-17 15:30:50 -08:00
|
|
|
|
2016-05-24 00:09:38 +02:00
|
|
|
|
|
|
|
|
|
2012-03-28 11:51:18 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-04 16:29:08 -07:00
|
|
|
|
2008-02-22 15:15:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG
This changes the stack protector config option into a choice of
"None", "Regular", and "Strong":
CONFIG_CC_STACKPROTECTOR_NONE
CONFIG_CC_STACKPROTECTOR_REGULAR
CONFIG_CC_STACKPROTECTOR_STRONG
"Regular" means the old CONFIG_CC_STACKPROTECTOR=y option.
"Strong" is a new mode introduced by this patch. With "Strong" the
kernel is built with -fstack-protector-strong (available in
gcc 4.9 and later). This option increases the coverage of the stack
protector without the heavy performance hit of -fstack-protector-all.
For reference, the stack protector options available in gcc are:
-fstack-protector-all:
Adds the stack-canary saving prefix and stack-canary checking
suffix to _all_ function entry and exit. Results in substantial
use of stack space for saving the canary for deep stack users
(e.g. historically xfs), and measurable (though shockingly still
low) performance hit due to all the saving/checking. Really not
suitable for sane systems, and was entirely removed as an option
from the kernel many years ago.
-fstack-protector:
Adds the canary save/check to functions that define an 8
(--param=ssp-buffer-size=N, N=8 by default) or more byte local
char array. Traditionally, stack overflows happened with
string-based manipulations, so this was a way to find those
functions. Very few total functions actually get the canary; no
measurable performance or size overhead.
-fstack-protector-strong
Adds the canary for a wider set of functions, since it's not
just those with strings that have ultimately been vulnerable to
stack-busting. With this superset, more functions end up with a
canary, but it still remains small compared to all functions
with only a small change in performance. Based on the original
design document, a function gets the canary when it contains any
of:
- local variable's address used as part of the right hand side
of an assignment or function argument
- local variable is an array (or union containing an array),
regardless of array type or length
- uses register local variables
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
Find below a comparison of "size" and "objdump" output when built with
gcc-4.9 in three configurations:
- defconfig
11430641 kernel text size
36110 function bodies
- defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
11468490 kernel text size (+0.33%)
1015 of 36110 functions are stack-protected (2.81%)
- defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
11692790 kernel text size (+2.24%)
7401 of 36110 functions are stack-protected (20.5%)
With -strong, ARM's compressed boot code now triggers stack
protection, so a static guard was added. Since this is only used
during decompression and was never used before, the exposure
here is very small. Once it switches to the full kernel, the
stack guard is back to normal.
Chrome OS has been using -fstack-protector-strong for its kernel
builds for the last 8 months with no problems.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org
[ Improved the changelog and descriptions some more. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-12-19 11:35:59 -08:00
|
|
|
|
2013-12-19 11:35:58 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
2014-02-25 15:01:48 -08:00
|
|
|
|
|
|
|
|
|
stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG
This changes the stack protector config option into a choice of
"None", "Regular", and "Strong":
CONFIG_CC_STACKPROTECTOR_NONE
CONFIG_CC_STACKPROTECTOR_REGULAR
CONFIG_CC_STACKPROTECTOR_STRONG
"Regular" means the old CONFIG_CC_STACKPROTECTOR=y option.
"Strong" is a new mode introduced by this patch. With "Strong" the
kernel is built with -fstack-protector-strong (available in
gcc 4.9 and later). This option increases the coverage of the stack
protector without the heavy performance hit of -fstack-protector-all.
For reference, the stack protector options available in gcc are:
-fstack-protector-all:
Adds the stack-canary saving prefix and stack-canary checking
suffix to _all_ function entry and exit. Results in substantial
use of stack space for saving the canary for deep stack users
(e.g. historically xfs), and measurable (though shockingly still
low) performance hit due to all the saving/checking. Really not
suitable for sane systems, and was entirely removed as an option
from the kernel many years ago.
-fstack-protector:
Adds the canary save/check to functions that define an 8
(--param=ssp-buffer-size=N, N=8 by default) or more byte local
char array. Traditionally, stack overflows happened with
string-based manipulations, so this was a way to find those
functions. Very few total functions actually get the canary; no
measurable performance or size overhead.
-fstack-protector-strong
Adds the canary for a wider set of functions, since it's not
just those with strings that have ultimately been vulnerable to
stack-busting. With this superset, more functions end up with a
canary, but it still remains small compared to all functions
with only a small change in performance. Based on the original
design document, a function gets the canary when it contains any
of:
- local variable's address used as part of the right hand side
of an assignment or function argument
- local variable is an array (or union containing an array),
regardless of array type or length
- uses register local variables
https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
Find below a comparison of "size" and "objdump" output when built with
gcc-4.9 in three configurations:
- defconfig
11430641 kernel text size
36110 function bodies
- defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
11468490 kernel text size (+0.33%)
1015 of 36110 functions are stack-protected (2.81%)
- defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
11692790 kernel text size (+2.24%)
7401 of 36110 functions are stack-protected (20.5%)
With -strong, ARM's compressed boot code now triggers stack
protection, so a static guard was added. Since this is only used
during decompression and was never used before, the exposure
here is very small. Once it switches to the full kernel, the
stack guard is back to normal.
Chrome OS has been using -fstack-protector-strong for its kernel
builds for the last 8 months with no problems.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mips@linux-mips.org
Cc: linux-arch@vger.kernel.org
Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org
[ Improved the changelog and descriptions some more. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-12-19 11:35:59 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
2013-12-19 11:35:58 -08:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-19 11:35:58 -08:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
2009-02-09 22:17:39 +09:00
|
|
|
|
2014-02-25 15:01:48 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
2018-02-06 15:37:41 -08:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
2016-07-26 14:26:20 -07:00
|
|
|
|
|
|
|
|
|
2018-02-06 15:37:38 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 15:37:41 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 15:37:41 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
2008-02-13 22:43:28 +01:00
|
|
|
|
2017-11-27 21:15:13 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-06 15:46:51 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-14 22:21:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-10 19:20:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-14 22:21:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-10 19:20:53 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
Michel Dänzer and a couple of other people reported inexplicable random
oopses in the scheduler, and the cause turns out to be gcc mis-compiling
the load_balance() function when debugging is enabled. The gcc bug
apparently goes back to gcc-4.5, but slight optimization changes means
that it now showed up as a problem in 4.9.0 and 4.9.1.
The instruction scheduling problem causes gcc to schedule a spill
operation to before the stack frame has been created, which in turn can
corrupt the spilled value if an interrupt comes in. There may be other
effects of this bug too, but that's the code generation problem seen in
Michel's case.
This is fixed in current gcc HEAD, but the workaround as suggested by
Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
when compiling the kernel, which disables the gcc code that causes the
problem. This can result in slightly worse debug information for
variable accesses, but that is infinitely preferable to actual code
generation problems.
Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
non-debug builds to verify that the debug build would be identical: we
can do
export GCC_COMPARE_DEBUG=1
to make gcc internally verify that the result of the build is
independent of the "-g" flag (it will make the compiler build everything
twice, toggling the debug flag, and compare the results).
Without the "-fno-var-tracking-assignments" option, the build would fail
(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
compare failure.
See also gcc bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Reported-by: Michel Dänzer <michel@daenzer.net>
Suggested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-07-26 14:52:01 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-07-30 20:50:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-14 22:21:35 +02:00
|
|
|
|
2014-07-30 20:50:18 +02:00
|
|
|
|
2014-02-14 15:19:17 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-07-30 20:50:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-07-14 15:43:52 +02:00
|
|
|
|
2013-02-07 13:58:40 -08:00
|
|
|
|
|
|
|
|
|
2010-07-14 15:43:52 +02:00
|
|
|
|
|
|
|
|
|
2008-10-06 19:06:12 -04:00
|
|
|
|
2015-01-09 13:06:33 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-09 13:15:59 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-09 13:06:33 +01:00
|
|
|
|
2011-02-09 13:15:59 -05:00
|
|
|
|
2010-10-13 17:12:30 -04:00
|
|
|
|
2010-10-14 23:32:44 -04:00
|
|
|
|
2010-10-13 17:12:30 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-12 21:20:42 +02:00
|
|
|
|
|
|
|
|
|
2008-01-21 21:31:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-04-14 15:17:26 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-30 16:51:42 -07:00
|
|
|
|
2017-10-16 10:12:46 -07:00
|
|
|
|
2005-04-30 16:51:42 -07:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-14 22:21:35 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2011-05-02 12:51:15 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-04-09 15:34:34 +04:00
|
|
|
|
2009-07-12 11:25:04 -07:00
|
|
|
|
2009-03-19 15:53:19 -07:00
|
|
|
|
kbuild: disable clang's default use of -fmerge-all-constants
Prasad reported that he has seen crashes in BPF subsystem with netd
on Android with arm64 in the form of (note, the taint is unrelated):
[ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
[ 4134.820925] Mem abort info:
[ 4134.901283] Exception class = DABT (current EL), IL = 32 bits
[ 4135.016736] SET = 0, FnV = 0
[ 4135.119820] EA = 0, S1PTW = 0
[ 4135.201431] Data abort info:
[ 4135.301388] ISV = 0, ISS = 0x00000021
[ 4135.359599] CM = 0, WnR = 0
[ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
[ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
[ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
[ 4135.674610] Modules linked in:
[ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1
[ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
[ 4135.731599] PC is at bpf_prog_add+0x20/0x68
[ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
[ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145
[ 4135.769062] sp : ffffff801d4e3ce0
[...]
[ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
[ 4136.273746] Call trace:
[...]
[ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
[ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
[ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68
[ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c
[ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c
[ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88
Android's netd was basically pinning the uid cookie BPF map in BPF
fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
again resulting in above panic. Issue is that the map was wrongly
identified as a prog! Above kernel was compiled with clang 4.0,
and it turns out that clang decided to merge the bpf_prog_iops and
bpf_map_iops into a single memory location, such that the two i_ops
could then not be distinguished anymore.
Reason for this miscompilation is that clang has the more aggressive
-fmerge-all-constants enabled by default. In fact, clang source code
has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
to do so:
Pointers with different bases cannot represent the same object.
(Note that clang defaults to -fmerge-all-constants, which can
lead to inconsistent results for comparisons involving the address
of a constant; this generally doesn't matter in practice.)
The issue never appeared with gcc however, since gcc does not enable
-fmerge-all-constants by default and even *explicitly* states in
it's option description that using this flag results in non-conforming
behavior, quote from man gcc:
Languages like C or C++ require each variable, including multiple
instances of the same variable in recursive calls, to have distinct
locations, so using this option results in non-conforming behavior.
There are also various clang bug reports open on that matter [1],
where clang developers acknowledge the non-conforming behavior,
and refer to disabling it with -fno-merge-all-constants. But even
if this gets fixed in clang today, there are already users out there
that triggered this. Thus, fix this issue by explicitly adding
-fno-merge-all-constants to the kernel's Makefile to generically
disable this optimization, since potentially other places in the
kernel could subtly break as well.
Note, there is also a flag called -fmerge-constants (not supported
by clang), which is more conservative and only applies to strings
and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
gcc's code, the two flags -fmerge-{all-,}constants share the same
variable internally, so when disabling it via -fno-merge-all-constants,
then we really don't merge any const data (e.g. strings), and text
size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).
$ gcc -fverbose-asm -O2 foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
-> foo.S doesn't list -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
Thus, as a workaround we need to set both -fno-merge-all-constants
*and* -fmerge-constants in the Makefile in order for text size to
stay as is.
[1] https://bugs.llvm.org/show_bug.cgi?id=18538
Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Richard Smith <richard-llvm@metafoo.co.uk>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: linux-kernel@vger.kernel.org
Tested-by: Prasad Sodagudi <psodagud@codeaurora.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-03-21 01:18:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-29 17:34:43 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-18 12:49:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-09-13 14:51:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-23 13:56:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-08 09:29:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-03-20 17:14:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-20 13:45:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 20:43:36 +09:00
|
|
|
|
|
|
|
|
|
2016-01-20 15:00:55 -08:00
|
|
|
|
2014-04-14 18:27:10 +09:00
|
|
|
|
2015-07-01 17:19:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-15 22:03:58 +02:00
|
|
|
|
2007-07-19 01:48:40 -07:00
|
|
|
|
2018-02-23 13:56:52 +09:00
|
|
|
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 17:33:09 +02:00
|
|
|
|
2007-07-19 01:48:40 -07:00
|
|
|
|
|
|
|
|
|
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 22:29:20 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-04 11:59:07 -08:00
|
|
|
|
2009-09-16 22:36:55 +02:00
|
|
|
|
2009-03-04 11:59:07 -08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-01 23:56:28 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-01-16 12:46:07 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-21 20:53:09 -04:00
|
|
|
|
2014-04-28 16:32:43 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-14 21:38:20 +01:00
|
|
|
|
2006-06-21 20:53:09 -04:00
|
|
|
|
|
|
|
|
|
2009-01-14 21:38:20 +01:00
|
|
|
|
2006-06-21 20:53:09 -04:00
|
|
|
|
2009-01-14 21:38:20 +01:00
|
|
|
|
2006-06-21 20:53:09 -04:00
|
|
|
|
|
|
|
|
|
2009-01-14 21:38:20 +01:00
|
|
|
|
2006-06-21 20:53:09 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-08-27 20:31:56 +09:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-07 20:26:07 +02:00
|
|
|
|
2014-08-27 20:31:56 +09:30
|
|
|
|
|
|
|
|
|
2015-07-07 20:26:07 +02:00
|
|
|
|
2014-08-27 20:31:56 +09:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-12 15:11:44 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-18 17:08:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-12-20 16:52:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-01-25 13:41:31 +10:30
|
|
|
|
2015-08-14 16:17:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-19 11:53:15 +10:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-15 12:21:17 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-10-13 15:02:00 -05:00
|
|
|
|
|
|
|
|
|
2017-10-03 20:10:36 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-15 12:21:17 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-19 11:53:15 +10:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-08-14 15:20:41 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-22 16:47:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2015-09-22 16:47:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-20 01:52:05 +10:00
|
|
|
|
2015-09-22 16:47:29 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-05 10:18:41 +02:00
|
|
|
|
2012-05-05 10:18:40 +02:00
|
|
|
|
2017-06-20 01:52:05 +10:00
|
|
|
|
|
|
|
|
|
2012-05-05 10:18:40 +02:00
|
|
|
|
2012-05-05 10:18:41 +02:00
|
|
|
|
2017-08-02 10:31:06 +08:00
|
|
|
|
2015-09-22 16:47:29 +08:00
|
|
|
|
2008-12-16 11:30:08 +00:00
|
|
|
|
2017-06-20 01:52:05 +10:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-04-22 15:25:00 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-10-11 01:21:43 -07:00
|
|
|
|
2006-10-13 16:04:23 +01:00
|
|
|
|
2007-10-18 23:41:07 -07:00
|
|
|
|
2015-02-17 13:46:36 -08:00
|
|
|
|
2017-08-20 15:04:11 +09:00
|
|
|
|
2006-10-11 01:21:43 -07:00
|
|
|
|
2016-04-22 15:25:00 -04:00
|
|
|
|
2016-04-25 17:55:08 +02:00
|
|
|
|
2016-12-02 15:11:50 -05:00
|
|
|
|
2016-04-22 15:25:00 -04:00
|
|
|
|
2016-01-26 21:50:18 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-25 17:55:08 +02:00
|
|
|
|
2016-01-26 21:50:18 -05:00
|
|
|
|
2016-08-24 22:29:21 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-02 10:31:06 +08:00
|
|
|
|
|
|
|
|
|
2016-08-24 22:29:21 +10:00
|
|
|
|
2016-04-22 15:25:00 -04:00
|
|
|
|
2016-04-26 16:48:44 -04:00
|
|
|
|
2012-05-05 10:18:41 +02:00
|
|
|
|
2007-07-17 10:54:06 +02:00
|
|
|
|
2016-02-28 22:00:00 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 16:26:18 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-05 10:18:41 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
2017-11-08 01:31:46 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-07-11 15:34:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-28 11:27:31 +02:00
|
|
|
|
2006-06-08 22:12:43 -07:00
|
|
|
|
2013-07-11 15:34:51 +02:00
|
|
|
|
2006-01-09 21:20:34 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
2005-09-09 19:28:28 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:43 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-11-06 03:31:35 -05:00
|
|
|
|
2006-06-08 22:12:39 -07:00
|
|
|
|
2012-07-07 23:04:40 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-02 18:01:56 +01:00
|
|
|
|
2009-10-18 00:00:43 +02:00
|
|
|
|
2007-10-19 22:20:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-05-08 21:22:24 +03:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
2016-05-24 00:09:38 +02:00
|
|
|
|
2005-09-10 21:05:36 +02:00
|
|
|
|
2005-09-09 19:28:28 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-02-28 22:22:42 -06:00
|
|
|
|
|
|
|
|
|
2017-10-04 12:56:06 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-28 22:22:42 -06:00
|
|
|
|
2016-03-03 11:39:30 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
2018-02-06 15:37:38 -08:00
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO
Nearly all modern compilers support a stack-protector option, and nearly
all modern distributions enable the kernel stack-protector, so enabling
this by default in kernel builds would make sense. However, Kconfig does
not have knowledge of available compiler features, so it isn't safe to
force on, as this would unconditionally break builds for the compilers or
architectures that don't have support. Instead, this introduces a new
option, CONFIG_CC_STACKPROTECTOR_AUTO, which attempts to discover the best
possible stack-protector available, and will allow builds to proceed even
if the compiler doesn't support any stack-protector.
This option is made the default so that kernels built with modern
compilers will be protected-by-default against stack buffer overflows,
avoiding things like the recent BlueBorne attack. Selection of a specific
stack-protector option remains available, including disabling it.
Additionally, tiny.config is adjusted to use CC_STACKPROTECTOR_NONE, since
that's the option with the least code size (and it used to be the default,
so we have to explicitly choose it there now).
Link: http://lkml.kernel.org/r/1510076320-69931-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-02-06 15:37:45 -08:00
|
|
|
|
2016-07-26 15:21:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-03 23:30:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-02-16 22:49:15 +01:00
|
|
|
|
|
|
|
|
|
2006-07-03 23:30:54 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2012-10-02 18:01:56 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-11-27 16:13:17 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-10-18 00:52:28 +02:00
|
|
|
|
2006-07-03 23:30:54 +02:00
|
|
|
|
|
|
|
|
|
2008-12-16 12:33:43 +01:00
|
|
|
|
|
|
|
|
|
2011-04-26 17:17:11 -04:00
|
|
|
|
|
|
|
|
|
2008-12-16 12:33:43 +01:00
|
|
|
|
2006-06-18 11:58:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-05 16:43:46 +02:00
|
|
|
|
|
|
|
|
|
2006-09-24 22:16:03 +01:00
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
|
|
|
|
|
2008-06-05 16:43:46 +02:00
|
|
|
|
2011-11-17 13:17:35 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-08 21:22:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-05 16:43:46 +02:00
|
|
|
|
2017-07-10 03:32:59 +09:00
|
|
|
|
2011-03-14 23:34:25 -07:00
|
|
|
|
2008-06-05 16:43:46 +02:00
|
|
|
|
|
|
|
|
|
2008-06-21 00:24:17 +02:00
|
|
|
|
|
|
|
|
|
2006-09-24 22:16:03 +01:00
|
|
|
|
2006-06-18 11:58:39 +01:00
|
|
|
|
2008-06-05 16:43:46 +02:00
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
2012-10-02 18:01:57 +01:00
|
|
|
|
2017-07-10 03:32:35 +09:00
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
2006-06-18 11:58:39 +01:00
|
|
|
|
2007-02-14 00:33:02 -08:00
|
|
|
|
|
|
|
|
|
2008-06-21 00:24:17 +02:00
|
|
|
|
2007-02-14 00:33:02 -08:00
|
|
|
|
2006-06-18 12:02:10 +01:00
|
|
|
|
|
|
|
|
|
2017-07-10 03:32:35 +09:00
|
|
|
|
2017-10-04 12:56:04 +09:00
|
|
|
|
2006-06-18 12:02:10 +01:00
|
|
|
|
2014-08-07 13:07:46 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-09-06 16:44:35 -06:00
|
|
|
|
2014-08-07 13:07:46 -06:00
|
|
|
|
2017-08-18 15:54:41 -06:00
|
|
|
|
2015-10-08 02:41:18 +00:00
|
|
|
|
2017-09-06 16:44:35 -06:00
|
|
|
|
2015-10-08 02:41:18 +00:00
|
|
|
|
2016-01-08 15:27:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-03-10 12:28:58 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-04-28 16:32:43 +09:00
|
|
|
|
2007-12-07 21:04:30 +09:00
|
|
|
|
2014-04-28 16:32:43 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2010-06-07 22:22:12 +02:00
|
|
|
|
2007-12-07 21:04:30 +09:00
|
|
|
|
2008-11-06 03:31:35 -05:00
|
|
|
|
2006-08-08 21:36:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-03-08 10:07:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-03-10 12:28:58 +01:00
|
|
|
|
2010-03-08 10:07:12 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-09-11 22:30:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2010-06-07 22:22:12 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-08-20 15:04:11 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-04-25 17:29:45 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-12-07 21:04:30 +09:00
|
|
|
|
2009-12-07 16:38:33 +01:00
|
|
|
|
2006-08-08 21:36:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-18 21:24:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2013-07-10 19:02:51 -07:00
|
|
|
|
2007-10-18 21:24:21 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-11-05 09:09:24 +10:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-13 09:39:22 +09:00
|
|
|
|
|
|
|
|
|
2012-07-07 23:04:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-27 22:29:49 +02:00
|
|
|
|
2014-04-28 16:32:43 +09:00
|
|
|
|
2017-09-22 14:31:13 +09:00
|
|
|
|
2012-10-02 14:35:24 +09:30
|
|
|
|
2015-07-20 21:16:30 +01:00
|
|
|
|
|
|
|
|
|
2015-02-17 13:46:36 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-04 02:55:59 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-10-29 11:23:02 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-29 11:23:02 +00:00
|
|
|
|
|
|
|
|
|
2016-08-24 22:29:21 +10:00
|
|
|
|
2012-10-29 11:23:02 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-14 11:50:01 -03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2017-01-22 23:02:32 +09:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-04 22:53:52 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-07 07:44:25 -03:00
|
|
|
|
|
|
|
|
|
2006-06-08 22:12:37 -07:00
|
|
|
|
2006-03-21 07:22:35 +01:00
|
|
|
|
2017-11-15 18:19:20 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-06 22:16:07 +02:00
|
|
|
|
2014-10-28 17:18:20 +04:00
|
|
|
|
2008-04-06 22:16:07 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-03-13 09:39:55 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-12 19:09:40 +01:00
|
|
|
|
2006-09-24 14:01:08 +02:00
|
|
|
|
2006-12-12 19:09:40 +01:00
|
|
|
|
2006-09-24 14:01:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-11-23 20:11:34 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2015-12-11 00:35:19 +08:00
|
|
|
|
2017-04-24 13:04:58 -07:00
|
|
|
|
|
|
|
|
|
2010-01-13 09:31:44 -08:00
|
|
|
|
|
|
|
|
|
2005-07-07 17:56:08 -07:00
|
|
|
|
2009-04-24 12:35:23 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-01-14 20:07:05 +08:00
|
|
|
|
2014-07-11 15:57:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-21 00:24:17 +02:00
|
|
|
|
2007-01-29 13:47:01 +01:00
|
|
|
|
2008-06-21 00:24:17 +02:00
|
|
|
|
2017-05-08 15:55:08 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-11-14 21:34:55 +01:00
|
|
|
|
2007-11-04 12:01:55 -08:00
|
|
|
|
2007-08-24 23:04:56 +02:00
|
|
|
|
2008-12-16 12:33:43 +01:00
|
|
|
|
2010-06-06 17:15:01 +02:00
|
|
|
|
2017-11-14 18:47:20 +09:00
|
|
|
|
2010-06-06 17:15:01 +02:00
|
|
|
|
2017-05-08 15:55:08 -07:00
|
|
|
|
2014-08-07 13:07:46 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 02:41:18 +00:00
|
|
|
|
2017-10-06 17:17:52 -07:00
|
|
|
|
2016-01-08 15:27:34 +08:00
|
|
|
|
2014-08-07 13:07:46 -06:00
|
|
|
|
2017-05-08 15:55:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-21 07:22:35 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-05-14 11:50:01 -03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-25 22:34:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-04-25 22:34:58 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-06 22:16:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-08-08 21:35:14 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2017-06-06 17:07:53 +08:00
|
|
|
|
2006-05-23 15:57:23 -05:00
|
|
|
|
2011-06-16 13:26:23 +02:00
|
|
|
|
2011-04-27 22:15:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-29 14:45:31 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-06 22:16:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-28 13:31:43 +01:00
|
|
|
|
2008-04-06 22:16:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2017-10-09 18:26:15 +03:00
|
|
|
|
|
|
|
|
|
Documentation/sphinx: add basic working Sphinx configuration and build
Add basic configuration and makefile to build documentation from any
.rst files under Documentation using Sphinx. For starters, there's just
the placeholder index.rst.
At the top level Makefile, hook Sphinx documentation targets alongside
(but independent of) the DocBook toolchain, having both be run on the
various 'make *docs' targets.
All Sphinx processing is placed into Documentation/Makefile.sphinx. Both
that and the Documentation/DocBook/Makefile are now expected to handle
all the documentation targets, explicitly ignoring them if they're not
relevant for that particular toolchain. The changes to the existing
DocBook Makefile are kept minimal.
There is graceful handling of missing Sphinx and rst2pdf (which is
needed for pdf output) by checking for the tool and python module,
respectively, with informative messages to the user.
If the Read the Docs theme (sphinx_rtd_theme) is available, use it, but
otherwise gracefully fall back to the Sphinx default theme, with an
informative message to the user, and slightly less pretty HTML output.
Sphinx can now handle htmldocs, pdfdocs (if rst2pdf is available),
epubdocs and xmldocs targets. The output documents are written into per
output type subdirectories under Documentation/output.
Finally, you can pass options to sphinx-build using the SPHINXBUILD make
variable. For example, 'make SPHINXOPTS=-v htmldocs' for more verbose
output from Sphinx.
This is based on the original work by Jonathan Corbet, but he probably
wouldn't recognize this as his own anymore.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-19 15:14:05 +03:00
|
|
|
|
|
|
|
|
|
2017-05-14 11:50:01 -03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-06-25 00:07:55 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-19 22:20:02 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-06 03:31:35 -05:00
|
|
|
|
2006-08-08 21:36:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2006-01-28 23:51:57 +01:00
|
|
|
|
2006-02-14 15:58:15 +01:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
|
|
|
|
|
2006-01-28 23:51:57 +01:00
|
|
|
|
|
|
|
|
|
2006-08-08 21:36:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2006-01-28 23:51:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-06 12:00:08 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-03-13 09:39:55 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-09-06 12:00:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-10 15:47:16 -07:00
|
|
|
|
2017-11-17 01:49:13 +09:00
|
|
|
|
2017-11-02 11:51:25 +09:00
|
|
|
|
2017-11-17 01:49:13 +09:00
|
|
|
|
2015-08-20 11:53:29 +02:00
|
|
|
|
2010-09-06 12:00:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
kbuild: Add a cache for generated variables
While timing a "no-op" build of the kernel (incrementally building the
kernel even though nothing changed) in the Chrome OS build system I
found that it was much slower than I expected.
Digging into things a bit, I found that quite a bit of the time was
spent invoking the C compiler even though we weren't actually building
anything. Currently in the Chrome OS build system the C compiler is
called through a number of wrappers (one of which is written in
python!) and can take upwards of 100 ms to invoke even if we're not
doing anything difficult, so these invocations of the compiler were
taking a lot of time. Worse the invocations couldn't seem to take
advantage of the multiple cores on my system.
Certainly it seems like we could make the compiler invocations in the
Chrome OS build system faster, but only to a point. Inherently
invoking a program as big as a C compiler is a fairly heavy
operation. Thus even if we can speed the compiler calls it made sense
to track down what was happening.
It turned out that all the compiler invocations were coming from
usages like this in the kernel's Makefile:
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
Due to the way cc-option and similar statements work the above
contains an implicit call to the C compiler. ...and due to the fact
that we're storing the result in KBUILD_CFLAGS, a simply expanded
variable, the call will happen every time the Makefile is parsed, even
if there are no users of KBUILD_CFLAGS.
Rather than redoing this computation every time, it makes a lot of
sense to cache the result of all of the Makefile's compiler calls just
like we do when we compile a ".c" file to a ".o" file. Conceptually
this is quite a simple idea. ...and since the calls to invoke the
compiler and similar tools are centrally located in the Kbuild.include
file this doesn't even need to be super invasive.
Implementing the cache in a simple-to-use and efficient way is not
quite as simple as it first sounds, though. To get maximum speed we
really want the cache in a format that make can natively understand
and make doesn't really have an ability to load/parse files. ...but
make _can_ import other Makefiles, so the solution is to store the
cache in Makefile format. This requires coming up with a valid/unique
Makefile variable name for each value to be cached, but that's
solvable with some cleverness.
After this change, we'll automatically create a ".cache.mk" file that
will contain our cached variables. We'll load this on each invocation
of make and will avoid recomputing anything that's already in our
cache. The cache is stored in a format that it shouldn't need any
invalidation since anything that might change should affect the "key"
and any old cached value won't be used.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2017-10-16 10:12:45 -07:00
|
|
|
|
2016-05-24 00:09:38 +02:00
|
|
|
|
2017-04-24 13:04:58 -07:00
|
|
|
|
2010-09-06 12:00:08 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2008-12-03 22:24:13 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-01-14 20:07:05 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-26 17:15:01 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-04-26 17:18:29 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-11-05 11:51:44 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2011-04-26 17:19:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-11-05 11:51:44 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-06-06 17:15:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-24 23:04:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-24 08:48:37 -04:00
|
|
|
|
2006-09-27 01:50:37 -07:00
|
|
|
|
2006-12-13 00:34:12 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-12-13 00:34:12 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2010-08-20 05:36:06 -04:00
|
|
|
|
|
|
|
|
|
2010-06-28 10:45:21 +08:00
|
|
|
|
2006-01-09 21:20:34 +01:00
|
|
|
|
2006-01-16 12:12:12 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-24 08:48:37 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-11 18:36:18 +02:00
|
|
|
|
|
|
|
|
|
2012-11-05 21:02:08 +00:00
|
|
|
|
2017-08-20 15:04:11 +09:00
|
|
|
|
2012-04-11 18:36:18 +02:00
|
|
|
|
|
|
|
|
|
2012-11-05 21:02:08 +00:00
|
|
|
|
2017-08-20 15:04:11 +09:00
|
|
|
|
2012-04-11 18:36:18 +02:00
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
|
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2008-02-03 15:14:02 +02:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-06 08:25:31 +02:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-03-05 12:10:58 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
kbuild: support for %.symtypes files
Here is a patch that adds a new -T option to genksyms for generating dumps of
the type definition that makes up the symbol version hashes. This allows to
trace modversion changes back to what caused them. The dump format is the
name of the type defined, followed by its definition (which is almost C):
s#list_head struct list_head { s#list_head * next , * prev ; }
The s#, u#, e#, and t# prefixes stand for struct, union, enum, and typedef.
The exported symbols do not define types, and thus do not have an x# prefix:
nfs4_acl_get_whotype int nfs4_acl_get_whotype ( char * , t#u32 )
The symbol type defintion of a single file can be generated with:
make fs/jbd/journal.symtypes
If KBUILD_SYMTYPES is defined, all the *.symtypes of all object files that
export symbols are generated.
The single *.symtypes files can be combined into a single file after a kernel
build with a script like the following:
for f in $(find -name '*.symtypes' | sort); do
f=${f#./}
echo "/* ${f%.symtypes}.o */"
cat $f
echo
done \
| sed -e '\:UNKNOWN:d' \
-e 's:[,;] }:}:g' \
-e 's:\([[({]\) :\1:g' \
-e 's: \([])},;]\):\1:g' \
-e 's: $::' \
$f \
| awk '
/^.#/ { if (defined[$1] == $0) {
print $1
next
}
defined[$1] = $0
}
{ print }
'
When the kernel ABI changes, diffing individual *.symtype files, or the
combined files, against each other will show which symbol changes caused the
ABI changes. This can save a tremendous amount of time.
Dump the types that make up modversions
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-05-09 20:37:30 +02:00
|
|
|
|
|
|
|
|
|
2017-04-24 13:04:58 -07:00
|
|
|
|
|
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2008-12-13 23:00:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-25 11:23:58 -07:00
|
|
|
|
2016-07-04 16:39:35 +02:00
|
|
|
|
2008-12-13 23:00:45 +01:00
|
|
|
|
2007-10-19 22:20:02 +02:00
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
|
|
|
|
|
2007-10-19 22:20:02 +02:00
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
2006-04-05 12:57:21 +02:00
|
|
|
|
2006-08-08 21:36:08 +02:00
|
|
|
|
2006-01-25 07:13:18 +01:00
|
|
|
|
2014-04-28 16:26:18 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-21 22:53:56 +00:00
|
|
|
|
2007-10-18 21:24:21 +02:00
|
|
|
|
2011-06-15 22:15:47 +02:00
|
|
|
|
2013-03-15 15:04:17 +10:30
|
|
|
|
2007-10-18 21:24:21 +02:00
|
|
|
|
2007-10-19 22:20:02 +02:00
|
|
|
|
2007-10-22 11:23:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-13 19:29:35 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
|
|
|
|
|
2009-04-09 15:34:34 +04:00
|
|
|
|
2006-03-05 17:14:10 -05:00
|
|
|
|
