.. 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.
Pull kbuild updates from Michal Marek:
- several cleanups in kbuild
- serialize multiple *config targets so that 'make defconfig kvmconfig'
works
- The cc-ifversion macro got support for an else-branch
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild,gcov: simplify kernel/gcov/Makefile more
kbuild: allow cc-ifversion to have the argument for false condition
kbuild,gcov: simplify kernel/gcov/Makefile
kbuild,gcov: remove unnecessary workaround
kbuild: do not add $(call ...) to invoke cc-version or cc-fullversion
kbuild: fix cc-ifversion macro
kbuild: drop $(version_h) from MRPROPER_FILES
kbuild: use mixed-targets when two or more config targets are given
kbuild: remove redundant line from bounds.h/asm-offsets.h
kbuild: merge bounds.h and asm-offsets.h rules
kbuild: Drop support for clean-rule
This provides the basic infrastructure to load kernel-specific python
helper scripts when debugging the kernel in gdb.
The loading mechanism is based on gdb loading for <objfile>-gdb.py when
opening <objfile>. Therefore, this places a corresponding link to the
main helper script into the output directory that contains vmlinux.
The main scripts will pull in submodules containing Linux specific gdb
commands and functions. To avoid polluting the source directory with
compiled python modules, we link to them from the object directory.
Due to gdb.parse_and_eval and string redirection for gdb.execute, we
depend on gdb >= 7.2.
This feature is enabled via CONFIG_GDB_SCRIPTS.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Michal Marek <mmarek@suse.cz> [kbuild stuff]
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Kernel Address sanitizer (KASan) is a dynamic memory error detector. It
provides fast and comprehensive solution for finding use-after-free and
out-of-bounds bugs.
KASAN uses compile-time instrumentation for checking every memory access,
therefore GCC > v4.9.2 required. v4.9.2 almost works, but has issues with
putting symbol aliases into the wrong section, which breaks kasan
instrumentation of globals.
This patch only adds infrastructure for kernel address sanitizer. It's
not available for use yet. The idea and some code was borrowed from [1].
Basic idea:
The main idea of KASAN is to use shadow memory to record whether each byte
of memory is safe to access or not, and use compiler's instrumentation to
check the shadow memory on each memory access.
Address sanitizer uses 1/8 of the memory addressable in kernel for shadow
memory and uses direct mapping with a scale and offset to translate a
memory address to its corresponding shadow address.
Here is function to translate address to corresponding shadow address:
unsigned long kasan_mem_to_shadow(unsigned long addr)
{
return (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET;
}
where KASAN_SHADOW_SCALE_SHIFT = 3.
So for every 8 bytes there is one corresponding byte of shadow memory.
The following encoding used for each shadow byte: 0 means that all 8 bytes
of the corresponding memory region are valid for access; k (1 <= k <= 7)
means that the first k bytes are valid for access, and other (8 - k) bytes
are not; Any negative value indicates that the entire 8-bytes are
inaccessible. Different negative values used to distinguish between
different kinds of inaccessible memory (redzones, freed memory) (see
mm/kasan/kasan.h).
To be able to detect accesses to bad memory we need a special compiler.
Such compiler inserts a specific function calls (__asan_load*(addr),
__asan_store*(addr)) before each memory access of size 1, 2, 4, 8 or 16.
These functions check whether memory region is valid to access or not by
checking corresponding shadow memory. If access is not valid an error
printed.
Historical background of the address sanitizer from Dmitry Vyukov:
"We've developed the set of tools, AddressSanitizer (Asan),
ThreadSanitizer and MemorySanitizer, for user space. We actively use
them for testing inside of Google (continuous testing, fuzzing,
running prod services). To date the tools have found more than 10'000
scary bugs in Chromium, Google internal codebase and various
open-source projects (Firefox, OpenSSL, gcc, clang, ffmpeg, MySQL and
lots of others): [2] [3] [4].
The tools are part of both gcc and clang compilers.
We have not yet done massive testing under the Kernel AddressSanitizer
(it's kind of chicken and egg problem, you need it to be upstream to
start applying it extensively). To date it has found about 50 bugs.
Bugs that we've found in upstream kernel are listed in [5].
We've also found ~20 bugs in out internal version of the kernel. Also
people from Samsung and Oracle have found some.
[...]
As others noted, the main feature of AddressSanitizer is its
performance due to inline compiler instrumentation and simple linear
shadow memory. User-space Asan has ~2x slowdown on computational
programs and ~2x memory consumption increase. Taking into account that
kernel usually consumes only small fraction of CPU and memory when
running real user-space programs, I would expect that kernel Asan will
have ~10-30% slowdown and similar memory consumption increase (when we
finish all tuning).
I agree that Asan can well replace kmemcheck. We have plans to start
working on Kernel MemorySanitizer that finds uses of unitialized
memory. Asan+Msan will provide feature-parity with kmemcheck. As
others noted, Asan will unlikely replace debug slab and pagealloc that
can be enabled at runtime. Asan uses compiler instrumentation, so even
if it is disabled, it still incurs visible overheads.
Asan technology is easily portable to other architectures. Compiler
instrumentation is fully portable. Runtime has some arch-dependent
parts like shadow mapping and atomic operation interception. They are
relatively easy to port."
Comparison with other debugging features:
========================================
KMEMCHECK:
- KASan can do almost everything that kmemcheck can. KASan uses
compile-time instrumentation, which makes it significantly faster than
kmemcheck. The only advantage of kmemcheck over KASan is detection of
uninitialized memory reads.
Some brief performance testing showed that kasan could be
x500-x600 times faster than kmemcheck:
$ netperf -l 30
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
no debug: 87380 16384 16384 30.00 41624.72
kasan inline: 87380 16384 16384 30.00 12870.54
kasan outline: 87380 16384 16384 30.00 10586.39
kmemcheck: 87380 16384 16384 30.03 20.23
- Also kmemcheck couldn't work on several CPUs. It always sets
number of CPUs to 1. KASan doesn't have such limitation.
DEBUG_PAGEALLOC:
- KASan is slower than DEBUG_PAGEALLOC, but KASan works on sub-page
granularity level, so it able to find more bugs.
SLUB_DEBUG (poisoning, redzones):
- SLUB_DEBUG has lower overhead than KASan.
- SLUB_DEBUG in most cases are not able to detect bad reads,
KASan able to detect both reads and writes.
- In some cases (e.g. redzone overwritten) SLUB_DEBUG detect
bugs only on allocation/freeing of object. KASan catch
bugs right before it will happen, so we always know exact
place of first bad read/write.
[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
[2] https://code.google.com/p/address-sanitizer/wiki/FoundBugs
[3] https://code.google.com/p/thread-sanitizer/wiki/FoundBugs
[4] https://code.google.com/p/memory-sanitizer/wiki/FoundBugs
[5] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel#Trophies
Based on work by Andrey Konovalov.
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Acked-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrey Konovalov <adech.fo@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Konstantin Serebryany <kcc@google.com>
Cc: Dmitry Chernenkov <dmitryc@google.com>
Cc: Yuri Gribov <tetra2005@gmail.com>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull s390 updates from Martin Schwidefsky:
- The remaining patches for the z13 machine support: kernel build
option for z13, the cache synonym avoidance, SMT support,
compare-and-delay for spinloops and the CES5S crypto adapater.
- The ftrace support for function tracing with the gcc hotpatch option.
This touches common code Makefiles, Steven is ok with the changes.
- The hypfs file system gets an extension to access diagnose 0x0c data
in user space for performance analysis for Linux running under z/VM.
- The iucv hvc console gets wildcard spport for the user id filtering.
- The cacheinfo code is converted to use the generic infrastructure.
- Cleanup and bug fixes.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: (42 commits)
s390/process: free vx save area when releasing tasks
s390/hypfs: Eliminate hypfs interval
s390/hypfs: Add diagnose 0c support
s390/cacheinfo: don't use smp_processor_id() in preemptible context
s390/zcrypt: fixed domain scanning problem (again)
s390/smp: increase maximum value of NR_CPUS to 512
s390/jump label: use different nop instruction
s390/jump label: add sanity checks
s390/mm: correct missing space when reporting user process faults
s390/dasd: cleanup profiling
s390/dasd: add locking for global_profile access
s390/ftrace: hotpatch support for function tracing
ftrace: let notrace function attribute disable hotpatching if necessary
ftrace: allow architectures to specify ftrace compile options
s390: reintroduce diag 44 calls for cpu_relax()
s390/zcrypt: Add support for new crypto express (CEX5S) adapter.
s390/zcrypt: Number of supported ap domains is not retrievable.
s390/spinlock: add compare-and-delay to lock wait loops
s390/tape: remove redundant if statement
s390/hvc_iucv: add simple wildcard matches to the iucv allow filter
...
If the kernel is compiled with function tracer support the -pg compile option
is passed to gcc to generate extra code into the prologue of each function.
This patch replaces the "open-coded" -pg compile flag with a CC_FLAGS_FTRACE
makefile variable which architectures can override if a different option
should be used for code generation.
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The introduction of the uapi directories in v3.7-rc1 moved some of the
generated headers from arch/*/include/generated to the uapi directory,
keeping the #include directives intact.
This creates a problem when bisecting, because the unversioned files are
not cleaned automatically by git and the compiler might include stale
headers as a result. Instead of cleaning them in the Makefiles, promote
arch/*/include/generated/uapi in the search path. Under normal
circumstances, there is no overlap between this uapi subdirectory and
its parent, so the include choices remain the same. We keep
arch/*/include/generated/uapi in the USERINCLUDE variable so that it is
usable standalone.
Note that we cannot completely swap the order of the uapi and
kernel-only directories, since the headers in include/uapi/asm-generic
are meant to be wrapped by their include/asm-generic counterparts when
building kernel code.
Reported-by: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
Reported-by: David Drysdale <dmd@lurklurk.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now $(version_h) is include/generated/uapi/linux/version.h.
$(version_h) in MRPROPER_FILES is redundant because it is covered
by include/generated in MRPROPER_DIRS.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
"make kvmconfig" expects that the .config has already been created,
but some people might want to create the .config and run kvmconfig
in one shot command, like this:
$ make defconfig kvmconfig
To make sure this command works correctly even if -j* option is set,
we must handle them one by one.
This commit turns on mixed-targets when $(MAKECMDGOALS) includes
at least one config target and also includes another target.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild updates from Michal Marek:
"Here are the kbuild changes for v3.19-rc1:
- Cleanups and deduplication in the main Makefile and
scripts/Makefile.*
- Sort the output of *config targets in make help
- Old <linux/version.h> is always removed to avoid a surprise during
bisecting
- Warning fix in kconfig"
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: remove redundant -rR flag of hdr-inst
kbuild: Fix make help-<board series> on powerpc
kbuild: Automatically remove stale <linux/version.h> file
kconfig: Fix warning "‘jump’ may be used uninitialized"
Makefile: sort list of defconfig targets in make help output
kbuild: Remove duplicate $(cmd) definition in Makefile.clean
kbuild: collect shorthands into scripts/Kbuild.include
make ARCH=powerpc help-<board series> should not require a cofigured
source tree. Also, sort the boards in the output.
Signed-off-by: Michal Marek <mmarek@suse.cz>
In 3.7, the file moved from include/linux/ to
include/generated/uapi/linux/. The path in the #include directive
remained the same for compatibility reasons, but this created a problem
when bisecting. Commit 9c8cdb71 (kbuild: unconditionally clobber
include/linux/version.h on distclean) fixes this, provided the user does
make distclean between builds. Better not rely on the user and delete
the stale file each time make is invoked.
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Without sorting this list is completely unreadable for ARCH=arm.
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The shorthand "clean" is defined in both the top Makefile and
scripts/Makefile.clean. Likewise, the "hdr-inst" is defined in
both the top Makefile and scripts/Makefile.headersinst.
To reduce code duplication, this commit collects them into
scripts/Kbuild.include like the "build" and "modbuiltin" shorthands.
It requires scripts/Makefile.clean to include scripts/Kbuild.include,
but its impact on the performance of "make clean" should be
negligible.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Sasha Levin reports:
"gcc5 changes the default standard to c11, which makes kernel build
unhappy
Explicitly define the kernel standard to be gnu89 which should keep
everything working exactly like it was before gcc5"
There are multiple small issues with the new default, but the biggest
issue seems to be that the old - and very useful - GNU extension to
allow a cast in front of an initializer has gone away.
Patch updated by Kirill:
"I'm pretty sure all gcc versions you can build kernel with supports
-std=gnu89. cc-option is redunrant.
We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me"
Note by Andrew Pinski:
"Yes it was reported and both problems relating to this extension has
been added to gnu99 and gnu11. Though there are other issues with the
kernel dealing with extern inline have different semantics between
gnu89 and gnu99/11"
End result: we may be able to move up to a newer stdc model eventually,
but right now the newer models have some annoying deficiencies, so the
traditional "gnu89" model ends up being the preferred one.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Singed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull kbuild changes from Michal Marek:
- fix for handling dependencies of *-objs targets by Masahiro Yamada
- lots of cleanups in the kbuild machinery, also by Masahiro
- fixes for the kconfig build to use an UTF-8 capable ncurses library
if possible and to build on not-so-standard installs
- some more minor fixes
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Do not reference *-n variables in the Makefile
kbuild: simplify build, clean, modbuiltin shorthands
kbuild: arm: Do not define "comma" twice
kbuild: remove obj-n and lib-n handling
kbuild: remove unnecessary variable initializaions
kbuild: remove unnecessary "obj- := dummy.o" trick
kbuild: handle C=... and M=... after entering into build directory
kbuild: use $(Q) for sub-make target
kbuild: fake the "Entering directory ..." message more simply
kconfig/lxdialog: get ncurses CFLAGS with pkg-config
kconfig: nconfig: fix multi-byte UTF handling
kconfig: lxdialog: fix spelling
kbuild: Make scripts executable
kbuild: remove redundant clean-files from scripts/kconfig/Makefile
kbuild: refactor script/kconfig/Makefile
kbuild: handle the dependency of multi-objs hostprogs appropriately
kbuild: handle multi-objs dependency appropriately
Pull documentation updates from Jiri Kosina:
"Updates to kernel documentation.
I took this over (hopefully temporarily) from Randy who was not
willing to maintain it any longer. This pile mostly is a relay of
queue that Randy already had in his tree"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/doc:
Documentation: fix broken v4l-utils URL
Documentation: update include path for mpssd
Documentation: correct parameter error for dma_mapping_error
MAINTAINERS: update location of linux-doc tree
Documentation: remove networking/.gitignore
tools: add more endian.h macros
Make Documenation depend on headers_install
Docs: this_cpu_ops: remove redundant add forms
Documentation: disable vdso_test to avoid breakage with old glibc
Documentation: update vDSO makefile to build portable examples
Documentation: update .gitignore files
Documentation: support glibc versions without htole macros
v4l2-pci-skeleton: Only build if PCI is available
Documentation: fix misc. warnings
Documentation: make functions static to avoid prototype warnings
Documentation: add makefiles for more targets
Documentation: use subdir-y to avoid unnecessary built-in.o files
Cheers,
Rusty.
PS. My virtio-next tree is empty: DaveM took the patches I had. There might
be a virtio-rng starvation fix, but so far it's a bit voodoo so I will
get to that in the next two days or it will wait.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUGFrvAAoJENkgDmzRrbjxOJYQALaZbTumrtX3Mo/FAtzn8d5N
8gxcqk1Mhz4lR1vPWy/YN/H2f23qb/saqLxPar8Wgou3h7N8EqSdwDqJSuvEqhG0
iEXUsNLC7BOsDkLYhdjTfZoW/lsVU/EH4bkZMSxAZI9V64phXhDYfPb5SQgJTECr
Ue6IK4ijW6zdWLstGfg/ixrIeGDUSnyiThF9O2mYVaB1D0QkLDIAZxbjZJgfFfut
PwO33/sEV4pceTpkmxFKl/OiS+obi/VbDixjSCcO+jaBd1pVxH9fhhKREStOhN4z
88z5ADR71RH6so9TQTwIIcgb2Hon5d+3RVMB6CxuvKs9NmHSXDiQyZvG9J/jiSdm
KrPKSiVwGGwJSwxXTm8CDaz6Oj0ibDXBIzv/vYI22sR7u8PmRQFvL3O1VrW+KDnE
yoG75S9DHzSQ1183xFFFTt4FBRm/4XKyVs+F6YqYkchLigrUfQMCGb1cmZyE5y7K
bgNyonu0m/ItoQmekoDgYqvSjwdguaJ35XCW55GrKJ84JDHBaw3SpPdEfjAS8FsH
aT5o2oernvwRG6gsX9858RvB/uo1UKwHv1waDfV4cqNjMm5Ko+Yr6OIdQvBQiq07
cFkVmkrMtEyX19QyIGW3QSbFL1lr3X5cC5glzEeKY941yZbTluSsNuMlMPT1+IMx
NOUbh0aG8B8ZaMZPFNLi
=QzCn
-----END PGP SIGNATURE-----
Merge tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux
Pull module update from Rusty Russell:
"Nothing major: support for compressing modules, and auto-tainting
params.
PS. My virtio-next tree is empty: DaveM took the patches I had. There
might be a virtio-rng starvation fix, but so far it's a bit voodoo
so I will get to that in the next two days or it will wait"
* tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
moduleparam: Resolve missing-field-initializer warning
kbuild: handle module compression while running 'make modules_install'.
modinst: wrap long lines in order to enhance cmd_modules_install
modsign: lookup lines ending in .ko in .mod files
modpost: simplify file name generation of *.mod.c files
modpost: reduce visibility of symbols and constify r/o arrays
param: check for tainting before calling set op.
drm/i915: taint the kernel if unsafe module parameters are set
module: add module_param_unsafe and module_param_named_unsafe
module: make it possible to have unsafe, tainting module params
module: rename KERNEL_PARAM_FL_NOARG to avoid confusion
$(if $(KBUILD_SRC),$(srctree)/) was a useful strategy
to omit a long absolute path for in-source-tree build
prior to commit 890676c65d
(kbuild: Use relative path when building in the source tree).
Now $(srctree) is "." when building in the source tree.
It would not be annoying to add "$(srctree)/" all the time.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This commit avoids processing C=... and M=... twice
when O=... is also given.
Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)"
in the sub-make target.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Since commit 066b7ed955
(kbuild: Do not print the build directory with make -s),
"Q" is defined above the sub-make target.
This commit takes advantage of that and replaces
"$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)".
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Commit c2e28dc975
(kbuild: Print the name of the build directory)
added a gimmick to show the "Entering directory ...".
Instead of echoing the hard-coded message (that is, we need to know
the exact message), moving --no-print-directory would be easier.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Peter Foley <pefoley2@pefoley.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Since module-init-tools (gzip) and kmod (gzip and xz) support compressed
modules, it could be useful to include a support for compressing modules
right after having them installed. Doing this in kbuild instead of per
distro can permit to make this kind of usage more generic.
This patch add a Kconfig entry to "Enable loadable module support" menu
and let you choose to compress using gzip (default) or xz.
Both gzip and xz does not used any extra -[1-9] option since Andi Kleen
and Rusty Russell prove no gain is made using them. gzip is called with -n
argument to avoid storing original filename inside compressed file, that
way we can save some more bytes.
On a v3.16 kernel, 'make allmodconfig' generated 4680 modules for a
total of 378MB (no strip, no sign, no compress), the following table
shows observed disk space gain based on the allmodconfig .config :
| time |
+-------------+-----------------+
| manual .ko | make | size | percent
| compression | modules_install | | gain
+-------------+-----------------+------+--------
- | | 18.61s | 378M |
GZIP | 3m16s | 3m37s | 102M | 73.41%
XZ | 5m22s | 5m39s | 77M | 79.83%
The gain for restricted environnement seems to be interesting while
uncompress can be time consuming but happens only while loading a module,
that is generally done only once.
This is fully compatible with signed modules while the signed module is
compressed. module-init-tools or kmod handles decompression
and provide to other layer the uncompressed but signed payload.
Reviewed-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Bertrand Jacquin <beber@meleeweb.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pull misc kbuild updates from Michal Marek:
"This is the non-critical part of kbuild for 3.17-rc1:
- make help hint to use make -s with make kernelrelease et al.
- moved a kbuild document to Documentation/kbuild where it belongs
- four new Coccinelle scripts, one dropped and one fixed
- new make kselftest target to run various tests on the kernel"
* 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: kselftest - new make target to build and run kernel selftests
Coccinelle: Script to replace if and BUG with BUG_ON
Coccinelle: Script to detect incorrect argument to sizeof
Coccinelle: Script to use ARRAY_SIZE instead of division of two sizeofs
Coccinelle: Script to detect cast after memory allocation
coccinelle/null: solve parse error
Documentation: headers_install.txt is part of kbuild
kbuild: make -s should be used with kernelrelease/kernelversion/image_name
Pull kbuild updates from Michal Marek:
- make clean also considers $(extra-m) and $(extra-) to be consistent
- cleanup and fixes in scripts/Makefile.host
- allow to override the name of the Python 2 executable with make
PYTHON=... (only needed for ia64 in practice)
- option to split debugingo into *.dwo files to save disk space if the
compiler supports it (CONFIG_DEBUG_INFO_SPLIT)
- option to use dwarf4 debuginfo if the compiler supports it
(CONFIG_DEBUG_INFO_DWARF4)
- fix for disabling certain warnings with clang
- fix for unneeded rebuild with dash when a command contains
backslashes
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Fix handling of backslashes in *.cmd files
kbuild, LLVMLinux: Supress warnings unless W=1-3
Kbuild: Add a option to enable dwarf4 v2
kbuild: Support split debug info v4
kbuild: allow to override Python command name
kbuild: clean-up and bug fix of scripts/Makefile.host
kbuild: clean up scripts/Makefile.host
kbuild: drop shared library support from Makefile.host
kbuild: fix a bug of C++ host program handling
kbuild: fix a typo in scripts/Makefile.host
scripts/Makefile.clean: clean also $(extra-m) and $(extra-)
Add a new make target "kselftest" to enable kernel testing. This
new target builds and runs kernel selftests. Running as root is
recommended for a complete test run as some tests don't run when
run by non-root user. Build, install, and boot kernel before
running kselftest on it.
Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
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>
This adds a hopefully helpful comment above the (seemingly weird) compiler
flag selection logic.
Signed-off-by: Kees Cook <keescook@chromium.org>
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
clang has more warnings enabled by default. Turn them off unless W is
set. This patch fixes a logic bug where warnings in clang were disabled
when W was set.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Cc: bp@alien8.de
Signed-off-by: Michal Marek <mmarek@suse.cz>
I found that a lot of unresolvable variables when using gdb on the
kernel become resolvable when dwarf4 is enabled. So add a Kconfig flag
to enable it.
It definitely increases the debug information size, but on the other
hand this isn't so bad when debug fusion is used.
v2: Use cc-option
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This is an alternative approach to lower the overhead of debug info
(as we discussed a few days ago)
gcc 4.7+ and newer binutils have a new "split debug info" debug info
model where the debug info is only written once into central ".dwo" files.
This avoids having to copy it around multiple times, from the object
files to the final executable. It lowers the disk space
requirements. In addition it defaults to compressed debug data.
More details here: http://gcc.gnu.org/wiki/DebugFission
This patch adds a new option to enable it. It has to be an option,
because it'll undoubtedly break everyone's debuginfo packaging scheme.
gdb/objdump/etc. all still work, if you have new enough versions.
I don't see big compile wins (maybe a second or two faster or so), but the
object dirs with debuginfo get significantly smaller. My standard kernel
config (slightly bigger than defconfig) shrinks from 2.9G disk space
to 1.1G objdir (with non reduced debuginfo). I presume if you are IO limited
the compile time difference will be larger.
Only problem I've seen so far is that it doesn't play well with older
versions of ccache (apparently fixed, see
https://bugzilla.samba.org/show_bug.cgi?id=10005)
v2: various fixes from Dirk Gouders. Improve commit message slightly.
v3: Fix clean rules and improve Kconfig slightly
v4: Fix merge error in last version (Sam Ravnborg)
Clarify description that it mainly helps disk size.
Cc: Dirk Gouders <dirk@gouders.net>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
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>
The specification of Python 3 is largely different from that of
Python 2.
For example, arch/ia64/scripts/unwcheck.py seems to be written
in Python 2, not compatible with Python 3.
It is not a good idea to invoke python scripts with the hard-coded
command name 'python'. The command 'python' could possibly be
Python 3 on some systems.
For that case, it is reasonable to allow to override the command name
by giving 'PYTHON=python2' from the command line.
The 'python' in arch/ia64/Makefile should be replaced with '$(PYTHON)'.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: linux-ia64@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.cz>
If .config has been edited, there will be a silentoldconfig run:
$ make defconfig
...
$ make kernelrelease
scripts/kconfig/conf --silentoldconfig Kconfig
3.16.0-rc1+
Recently, kbuild started to print the name of the build directory when
using O=
$ make O=build kernelrelease
make[1]: Entering directory `/dev/shm/mmarek/linux-2.6/build'
3.16.0-rc1+
Since these targets are often used in scripts, add a hint to use make -s
to the help text.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild fixes from Michal Marek:
"Three more fixes for the relative build dir feature:
- Shut up make -s again
- Fix for rpm/deb/tar-pkg with O=<subdir>
- Fix for CONFIG_EXTRA_FIRMWARE"
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
firmware: Create directories for external firmware
kbuild: Fix packaging targets with relative $(srctree)
kbuild: Do not print the build directory with make -s
All other users of Makefile.build set $(obj) to the name of the
subdirectory to build. Do the same for the packaging targets, otherwise
the build fails if $(srctree) is a relative directory:
$ make O=build tar-pkg
make[1]: Entering directory `/home/mmarek/linux-2.6/build'
CHK include/config/kernel.release
../scripts/Makefile.build:44: ../../scripts/package/Makefile: No such file or directory
make[2]: *** No rule to make target `../../scripts/package/Makefile'. Stop.
Fixes: 9da0763b ("kbuild: Use relative path when building in a subdir of the source tree")
Signed-off-by: Michal Marek <mmarek@suse.cz>
Commit c2e28dc9 (kbuild: Print the name of the build directory) prints
the name of the build directory for O= builds, but we should not be
doing this in make -s mode, so that commands like
make -s O=<dir> kernelrelease
can be used by scripts. This matches the behavior of make itself, where
the -s option implies --no-print-directory.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild fix from Michal Marek:
"There is one more fix for the relative paths series from -rc1: Print
the path to the build directory at the start of the build, so that
editors and IDEs can match the relative paths to source files"
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Print the name of the build directory
With commit 9da0763b (kbuild: Use relative path when building in a
subdir of the source tree), the compiler messages include relative
paths. These are however relative to the build directory, not the
directory where make was started. Print the "Entering directory ..."
message once, so that IDEs/editors can find the source files.
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild updates from Michal Marek:
"Kbuild changes for v3.16-rc1:
- cross-compilation fix so that cc-option is testing the right
compiler
- Fix for make defconfig all
- Using relative paths to the object and source directory where
possible, plus fixes for the fallout of the change
- several cleanups in the Makefiles and scripts
The powerpc fix is from today, because it was only discovered
recently. The rest has been in linux-next for some time"
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
powerpc: Avoid circular dependency with zImage.%
kbuild: create include/config directory in scripts/kconfig/Makefile
kbuild: do not create include/linux directory
Makefile: Fix unrecognized cross-compiler command line options
kbuild: do not add "selinux" to subdir- twice
um: Fix for relative objtree when generating x86 headers
kbuild: Use relative path when building in a subdir of the source tree
kbuild: Use relative path when building in the source tree
kbuild: Use relative path for $(objtree)
firmware: Use $(quote) in the Makefile
firmware: Simplify directory creation
kbuild: trivial - fix comment block indent
kbuild: trivial - remove trailing spaces
kbuild: support simultaneous "make %config" and "make all"
kbuild: move extra gcc checks to scripts/Makefile.extrawarn
The directory include/config is used only for
silentoldconfig, localmodconfig, localyesconfig.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
There are no generated files under include/linux directory.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
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 e74fc973b6 ("Turn off
-Wmaybe-uninitialized when building with -Os"),
- commit 61163efae0 ("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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlOTY+wACgkQuseO5dulBZXrIgCdFZyXRojufLLKikWEvHjZ3/k5
KsQAnimtcge+62/IX7YwDjWS+xg9Wt3m
=yPrI
-----END PGP SIGNATURE-----
Merge tag 'llvmlinux-for-v3.16' of git://git.linuxfoundation.org/llvmlinux/kernel
Pull LLVM patches from Behan Webster:
"Next set of patches to support compiling the kernel with clang.
They've been soaking in linux-next since the last merge window.
More still in the works for the next merge window..."
* tag 'llvmlinux-for-v3.16' of git://git.linuxfoundation.org/llvmlinux/kernel:
arm, unwind, LLVMLinux: Enable clang to be used for unwinding the stack
ARM: LLVMLinux: Change "extern inline" to "static inline" in glue-cache.h
all: LLVMLinux: Change DWARF flag to support gcc and clang
net: netfilter: LLVMLinux: vlais-netfilter
crypto: LLVMLinux: aligned-attribute.patch
Both gcc (well, actually gnu as) and clang support the "-Wa,-gdwarf-2" option
(though clang does not support "-Wa,--gdwarf-2"). Since these flags are equivalent
in meaning, this patch uses the one which is better supported across compilers.
Signed-off-by: Behan Webster <behanw@converseincode.com>
When doing make O=<subdir>, use '..' to refer to the source tree. This
allows for more readable compiler messages, and, more importantly, it
sets the VPATH to '..', so filenames in WARN_ON() etc. will be shorter.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
When not using O=, $(srctree) refers to the same directory as
$(objtree), so we can set it to '.' as well. This makes the default
include path more compact and results in more readable messages from the
compiler. The only case where we need the absolute path is when creating
the 'source' symlink in /lib/modules.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The main Makefile sets its working directory to the object tree and
never changes it again. Therefore, we can use '.' instead of the
absolute path. The only case where we need the absolute path is when
creating the 'build' symlink in /lib/modules.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Kbuild is supposed to support mixed targets. (%config and build targets)
But "make all" did nothing if it was run with configuration targets.
For example,
$ LANG=C make defconfig all
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
make: Nothing to be done for `all'.
This commits allows "make %config all" and makes sure
mixed targets are built one by one in the given order.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Michal Marek <mmarek@suse.cz>
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
W=... provides extra gcc checks.
Having such code in scripts/Makefile.build results in the same flags
being added to KBUILD_CFLAGS multiple times becuase
scripts/Makefile.build is invoked every time Kbuild descends into
the subdirectories.
Since the top Makefile is already too cluttered, this commit moves
all of extra gcc check stuff to a new file scripts/Makefile.extrawarn,
which is included from the top Makefile.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
CC: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull misc kbuild changes from Michal Marek:
"Here is the non-critical part of kbuild:
- One bogus coccinelle check removed, one check fixed not to suggest
the obsolete PTR_RET macro
- scripts/tags.sh does not index the generated *.mod.c files
- new objdiff tool to list differences between two versions of an
object file
- A fix for scripts/bootgraph.pl"
* 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
scripts/coccinelle: Use PTR_ERR_OR_ZERO
scripts/bootgraph.pl: Add graphic header
scripts: objdiff: detect object code changes between two commits
Coccicheck: Remove memcpy to struct assignment test
scripts/tags.sh: Ignore *.mod.c
Add support to toplevel Makefile for compiling with clang, both for
HOSTCC and CC. Use cc-option to prevent gcc option from breaking clang, and
from clang options from breaking gcc.
Clang 3.4 semantics are the same as gcc semantics for unsupported flags. For
unsupported warnings clang 3.4 returns true but shows a warning and gcc shows
a warning and returns false.
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Jan-Simon Möller <dl9pf@gmx.de>
Signed-off-by: Mark Charlebois <charlebm@gmail.com>
Cc: PaX Team <pageexec@freemail.hu>
objdiff is useful when doing large code cleanups. For example, when
removing checkpatch warnings and errors from new drivers in the staging
tree.
objdiff can be used in conjunction with a git rebase to confirm that
each commit made no changes to the resulting object code. It has the
same return values as diff(1).
This was written specifically to support adding the skein and threefish
cryto drivers to the staging tree. I needed a programmatic way to
confirm that commits changing >90% of the lines didn't inadvertently
change the code.
Temporary files (objdump output) are stored in
/path/to/linux/.tmp_objdiff
'make mrproper' will remove this directory.
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull kbuild changes from Michal Marek:
- cleanups in the main Makefiles and Documentation/DocBook/Makefile
- make O=... directory is automatically created if needed
- mrproper/distclean removes the old include/linux/version.h to make
life easier when bisecting across the commit that moved the version.h
file
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: docbook: fix the include error when executing "make help"
kbuild: create a build directory automatically for out-of-tree build
kbuild: remove redundant '.*.cmd' pattern from make distclean
kbuild: move "quote" to Kbuild.include to be consistent
kbuild: docbook: use $(obj) and $(src) rather than specific path
kbuild: unconditionally clobber include/linux/version.h on distclean
kbuild: docbook: specify KERNELDOC dependency correctly
kbuild: docbook: include cmd files more simply
kbuild: specify build_docproc as a phony target
Updates to devicetree core code. This branch contains the following notable changes:
* Add reserved memory binding
* Make struct device_node a kobject and remove legacy /proc/device-tree
* ePAPR conformance fixes
* Update in-kernel DTC copy to version v1.4.0
* Preparation changes for dynamic device tree overlays
* minor bug fixes and documentation changes
The most significant change in this branch is the conversion of struct
device_node to be a kobject that is exposed via sysfs and removal of the
old /proc/device-tree code. This simplifies the device tree handling
code and tightens up the lifecycle on device tree nodes.
[updated: added fix for dangling select PROC_DEVICETREE]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTOyNwAAoJEMWQL496c2LNZY0QAIreUrpo3/hKRau61EDPXkOA
UFRyPUHD0k/dNXWWDbTfvKH/nAfzdVwejhePqEWiODiFOFkq7JyQlMKPA+CZuZj0
ygN4215A1yj/hDf6JRD5Zn4WGpawDt9InlbZSps6P5dd8voV5t5dz6uzz+Y7uqaK
CAjTDlBSmxEen5vRHiHQgKv74au/+b9yfSURjPQVWg46+wl3WJwjsdzerphm4unW
tpEr8zkIsm51mqqAx4penIuiovh7+L2J5v4BFeg8o+kaZEuZpVxLHJPOuBd5hdom
zeqEIj3AqHTh5suYIHe4aAbZ2wMP3kYGgkPGwfWLnwLyULxalcCtGZeaCi9nwTFj
Fdj+7f17ocrt5mif0f5Deufi1LqJsDjhY6G9p7HuV7Y9hsMILpJIUoGENPji+TWj
BA4L45eaPmNYdKJytEtFD7F2WnXeHZ6fDtYho/39DWW+Bt16IFX85T199irhxGG4
byN6LRaahk2UeycSXkQHAlWOQHqzBcJJAkQLN2iahzyYRr9Dy+VI2E9clm53m49O
YQYcONdUlMYrtfRwJpbB9XHM0HgZUvg0LT5z/iHQs9uJtoo33Oj+zxFixyZLQ9Dq
qyLqQWEpV9gFLAo9tpf56gffkLiJRsHkX4UJ6oTtj4DY1WWU9H81jjCvv/7flzp/
8ZyyZzANQf1DZ9kqO2v+
=lyA5
-----END PGP SIGNATURE-----
Merge tag 'dt-for-linus' of git://git.secretlab.ca/git/linux
Pull devicetree changes from Grant Likely:
"Updates to devicetree core code. This branch contains the following
notable changes:
- add reserved memory binding
- make struct device_node a kobject and remove legacy
/proc/device-tree
- ePAPR conformance fixes
- update in-kernel DTC copy to version v1.4.0
- preparatory changes for dynamic device tree overlays
- minor bug fixes and documentation changes
The most significant change in this branch is the conversion of struct
device_node to be a kobject that is exposed via sysfs and removal of
the old /proc/device-tree code. This simplifies the device tree
handling code and tightens up the lifecycle on device tree nodes.
[updated: added fix for dangling select PROC_DEVICETREE]"
* tag 'dt-for-linus' of git://git.secretlab.ca/git/linux: (29 commits)
dt: Remove dangling "select PROC_DEVICETREE"
of: Add support for ePAPR "stdout-path" property
of: device_node kobject lifecycle fixes
of: only scan for reserved mem when fdt present
powerpc: add support for reserved memory defined by device tree
arm64: add support for reserved memory defined by device tree
of: add missing major vendors
of: add vendor prefix for SMSC
of: remove /proc/device-tree
of/selftest: Add self tests for manipulation of properties
of: Make device nodes kobjects so they show up in sysfs
arm: add support for reserved memory defined by device tree
drivers: of: add support for custom reserved memory drivers
drivers: of: add initialization code for dynamic reserved memory
drivers: of: add initialization code for static reserved memory
of: document bindings for reserved-memory nodes
Revert "of: fix of_update_property()"
kbuild: dtbs_install: new make target
ARM: mvebu: Allows to get the SoC ID even without PCI enabled
of: Allows to use the PCI translator without the PCI core
...
Kbuild supports saving output files in a separate directory.
But the build directory must be created beforehand. For example,
$ mkdir -p dir/to/store/output/files
$ make O=dir/to/store/output/files defconfig
Creating a build directory automatically would be useful.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
'.*.cmd' files are cleaned-up by "make clean".
The same pattern in "make distclean" is unnecessary.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
As of v3.7, the UAPI changes relocated headers around such that the
kernel version header lived in a new place.
If a person is bisecting and if you go back to pre-UAPI days,
you will create an include/linux/version.h -- then if you checkout a
post-UAPI kernel, and even run "make distclean" it still won't delete
that old version file. So you get a situation like this:
$ grep -R LINUX_VERSION_CODE include/
include/generated/uapi/linux/version.h:#define LINUX_VERSION_CODE 200192
include/linux/version.h:#define LINUX_VERSION_CODE 132646
The value in that second line is representative of a v2.6.38 version.
And it will be sourced/used, hence leading to strange behaviours, such
as drivers/staging content (which typically hasn't been purged of version
ifdefs) failing to build.
Since it is a subtle mode of failure, lets always clobber the old
file when doing a distclean.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions. Commit 8779657d29
("stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG") however
introduced an "else ifdef" construct which make 3.80 doesn't understand.
Also correct a warning message still referencing the old config option
name.
Apart from that I question the use of "ifdef" here (but it was used that
way already prior to said commit): ifeq (,y) would seem more to the
point.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
An extra parenthesis typo introduced in 19952a9203 ("stackprotector:
Unify the HAVE_CC_STACKPROTECTOR logic between architectures") is
causing the following error when CONFIG_CC_STACKPROTECTOR_REGULAR is
enabled:
Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR: -fstack-protector not supported by compiler
Makefile:608: *** missing separator. Stop.
Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Unlike other build products in the Linux kernel, there is no 'make
*install' mechanism to put devicetree blobs in a standard place.
This commit adds a new 'dtbs_install' make target which copies all of
the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
set before calling make to change the default install directory. If not
set then it defaults to:
$INSTALL_PATH/dtbs/$KERNELRELEASE.
This is done to keep dtbs from different kernel versions separate until
things have settled down. Once the dtbs are stable, and not so strongly
linked to the kernel version, the devicetree files will most likely move
to their own repo. Users will need to upgrade install scripts at that
time.
v7: (reworked by Grant Likely)
- Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
that each dtb install could have a separate target and be reported as
part of the make output.
- Fixed dependency problem to ensure $KERNELRELEASE is calculated before
attempting to install
- Removed option to call external script. Copying the files should be
sufficient and a build system can post-process the install directory.
Despite the fact an external script is used for installing the kernel,
I don't think that is a pattern that should be encouraged. I would
rather see buildroot type tools post process the install directory to
rename or move dtb files after installing to a staging directory.
- Plus it is easy to add a hook after the fact without blocking the
rest of this feature.
- Move the helper targets into scripts/Makefile.lib with the rest of the
common dtb rules
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
CONFIG_MODVERSIONS=y results in a .mod.c for every compiled file in the
kernel. Issuing a 'make cscope' on a compiled kernel tree results in
the cscope files containing *.mod.c files.
[prarit@prarit linux]# make cscope
[prarit@prarit linux]# cat cscope.files | grep mod.c | wc -l
4807
These files are not useful for cscope and should be ignored. For example,
# line filename / context / line
1 105 arch/x86/kvm/kvm-intel.mod.c <<GLOBAL>>
{ 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
2 508 drivers/block/mtip32xx/mtip32xx.h <<GLOBAL>>
int numa_node;
3 55 drivers/block/mtip32xx/mtip32xx.mod.c <<GLOBAL>>
{ 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
4 37 drivers/cpufreq/acpi-cpufreq.mod.c <<GLOBAL>>
{ 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
<snip>
Add an export to RCS_FIND_IGNORE so it can be used in scripts/tags.sh
and add explicitly ignore *.mod.c files.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Kirill Tkhai <tkhai@yandex.ru>
Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull __TIME__/__DATE__ removal from Michal Marek:
"This series by Josh finishes the removal of __DATE__ and __TIME__ from
the kernel. The last patch adds -Werror=date-time to KBUILD_CFLAGS to
stop these from reappearing.
Part of the series went through Greg's trees during this merge window,
which is why this pull request is not based on v3.13-rc1"
* 'drop-time' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
Makefile: Build with -Werror=date-time if the compiler supports it
x86: math-emu: Drop already-disabled print of build date
net: wireless: brcm80211: Drop debug version with build date/time
mtd: denali: Drop print of build date/time
Pull kbuild changes from Michal Marek:
- fix make -s detection with make-4.0
- fix for scripts/setlocalversion when the kernel repository is a
submodule
- do not hardcode ';' in macros that expand to assembler code, as some
architectures' assemblers use a different character for newline
- Fix passing --gdwarf-2 to the assembler
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
frv: Remove redundant debugging info flag
mn10300: Remove redundant debugging info flag
kbuild: Fix debugging info generation for .S files
arch: use ASM_NL instead of ';' for assembler new line character in the macro
kbuild: Fix silent builds with make-4
Fix detectition of kernel git repository in setlocalversion script [take #2]
GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use
of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build
non-deterministic. Now that the kernel does not use any of those
macros, turn on -Werror=date-time if available, to keep it that way.
The kernel already (optionally) records this information at build time
in a single place; other kernel code should not duplicate that.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change the debuging info generation flag in KBUILD_AFLAGS from '-gdwarf-2' to
'-Wa,--gdwarf-2'. This will properly generate the debugging info for .S files
when CONFIG_DEBUG_INFO=y.
It seems current gcc does not pass a '--gdwarf-2' option on to the assembler
when '-gdwarf-2' is on its command line (note the differece in the gcc and as
flags). This change provides the correct assembler flag to gcc, and so does
not rely on gcc to emit a flag for the assembler.
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Michal Marek <mmarek@suse.cz>
Pull strong stackprotector support from Ingo Molnar:
"This tree adds a CONFIG_CC_STACKPROTECTOR_STRONG=y, a new, stronger
stack canary checking method supported by the newest GCC versions (4.9
and later).
Here's the 'intensity comparison' between the various protection
modes:
- 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%)
the strong model comes with non-trivial costs, which is why we
preserved the 'regular' and 'none' models as well"
* 'core-stackprotector-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG
stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures
make-4 changed the way/order it presents the command line options
into MAKEFLAGS
In make-3.8x, '-s' would always be first into a group of options
with the '-'/hyphen removed
$ make -p -s 2>/dev/null | grep ^MAKEFLAGS
MAKEFLAGS = sp
In make-4, '-s' seems to always be last into a group of options
with the '-'/hyphen removed
$ make -s -p 2>/dev/null | grep ^MAKEFLAGS
MAKEFLAGS = ps
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Commit 1bf49dd4be ("./Makefile: export initial ramdisk compression
config option") started setting the INITRD_COMPRESS environment variable
depending on which decompression models the kernel had available.
That is completely broken.
For example, we by default have CONFIG_RD_LZ4 enabled, and are able to
decompress such an initrd, but the user tools to *create* such an initrd
may not be availble. So trying to tell dracut to generate an
lz4-compressed image just because we can decode such an image is
completely inappropriate.
Cc: J P <ppandit@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
Instead of duplicating the CC_STACKPROTECTOR Kconfig and
Makefile logic in each architecture, switch to using
HAVE_CC_STACKPROTECTOR and keep everything in one place. This
retains the x86-specific bug verification scripts.
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: Thomas Gleixner <tglx@linutronix.de>
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-2-git-send-email-keescook@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
According to Documentation/Changes, make 3.80 is still being supported
for building the kernel, hence make files must not make (unconditional)
use of features introduced only in newer versions.
Commit 1bf49dd4be ("./Makefile: export initial ramdisk compression
config option") however introduced "else ifeq" constructs which make
3.80 doesn't understand. Replace the logic there with more conventional
(in the kernel build infrastructure) list constructs (except that the
list here is intentionally limited to exactly one element).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: P J P <ppandit@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull kbuild changes from Michal Marek:
- LTO fixes, but the kallsyms part had to be reverted
- Pass -Werror=implicit-int and -Werror=strict-prototypes to the
compiler by default
- snprintf fix in modpost
- remove GREP_OPTIONS from the environment to be immune against exotic
grep option settings
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kallsyms: Revert back to 128 max symbol length
Kbuild: Ignore GREP_OPTIONS env variable
scripts: kallsyms: Use %zu to print 'size_t'
scripts/bloat-o-meter: use .startswith rather than fragile slicing
scripts/bloat-o-meter: ignore changes in the size of linux_banner
kbuild: replace unbounded sprintf call in modpost
kbuild, bloat-o-meter: fix static detection
Kbuild: Handle longer symbols in kallsyms.c
kbuild: Increase kallsyms max symbol length
Makefile: enable -Werror=implicit-int and -Werror=strict-prototypes by default
Make menuconfig allows one to choose compression format of an initial
ramdisk image. But this choice does not result in duly compressed ramdisk
image. Because - $ make install - does not pass on the selected
compression choice to the dracut(8) tool, which creates the initramfs
file. dracut(8) generates the image with the default compression, ie.
gzip(1).
This patch exports the selected compression option to a sub-shell
environment, so that it could be used by dracut(8) tool to generate
appropriately compressed initramfs images.
There isn't a straightforward way to pass on options to dracut(8) via
positional parameters. Because it is indirectly invoked at the end of a $
make install sequence.
# make install
-> arch/$arch/boot/Makefile
-> arch/$arch/boot/install.sh
-> /sbing/installkernel ...
-> /sbin/new-kernel-pkg ...
-> /sbin/dracut ...
Signed-off-by: P J P <ppandit@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When building the kernel in a shell which defines GREP_OPTIONS so that
grep behavior is modified, we can break the generation of the syscalls
table like so:
__SYSCALL_COMMON(^[[01;31m^[[K0^[[m^[[K, sys_read, sys_read)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K, sys_write, sys_write)
__SYSCALL_COMMON(^[[01;31m^[[K1^[[m^[[K0, sys_mprotect, sys_mprotect) ...
This is just the initial breakage, later we barf when generating
modules.
In this case, GREP_OPTIONS contains "--color=always" which adds the shell
colors markup and completely fudges the headers under ...generated/asm/.
Fix that by unexporting the GREP_OPTIONS variable for the whole kernel
build as we tend to use grep at a bunch of places.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Michal Marek <mmarek@suse.cz>
The common error found in forward-ported/backported patches is missing
headers. One recent example (files and function names are mangled):
void foo(){}
EXPORT_SYMBOL(foo);
gave only warning
foo.c:12345678:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
void foo(){}
^
foo.c:12345679:5: warning: data definition has no type or storage class [enabled by default]
EXPORT_SYMBOL(foo);
foo.c:12345679:5: warning: type defaults to 'int' in declaration of 'EXORT_SYMBOL' [-Werror=implicit-int]
Now it's a fatal error. Tested on x86_64 allyesconfig.
[akpm@linux-foundation.org: fix typos in comments]
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
