History log of /linux-master/Makefile
Revision Date Author Comments
# 156102fe 10-Sep-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: drop GCC < 5 -fno-var-tracking-assignments workaround

Now that GCC 5.1 is the minimally supported version, we can drop this
workaround for older versions of GCC.

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 6880fa6c 12-Sep-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.15-rc1


# 49832c81 07-Sep-2021 Randy Dunlap <rdunlap@infradead.org>

Makefile: use -Wno-main in the full kernel tree

When using gcc (SUSE Linux) 7.5.0 (on openSUSE 15.3), I see a build
warning:

kernel/trace/trace_osnoise.c: In function 'start_kthread':
kernel/trace/trace_osnoise.c:1461:8: warning: 'main' is usually a function [-Wmain]
void *main = osnoise_main;
^~~~

Quieten that warning by using "-Wno-main". It's OK to use "main" as a
declaration name in the kernel.

Build-tested on most ARCHes.

[ v2: only do it for gcc, since clang doesn't have that particular warning ]

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/lkml/20210813224131.25803-1-rdunlap@infradead.org/
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 3fe617cc 05-Sep-2021 Linus Torvalds <torvalds@linux-foundation.org>

Enable '-Werror' by default for all kernel builds

... but make it a config option so that broken environments can disable
it when required.

We really should always have a clean build, and will disable specific
over-eager warnings as required, if we can't fix them. But while I
fairly religiously enforce that in my own tree, it doesn't get enforced
by various build robots that don't necessarily report warnings.

So this just makes '-Werror' a default compiler flag, but allows people
to disable it for their configuration if they have some particular
issues.

Occasionally, new compiler versions end up enabling new warnings, and it
can take a while before we have them fixed (or the warnings disabled if
that is what it takes), so the config option allows for that situation.

Hopefully this will mean that I get fewer pull requests that have new
warnings that were not noticed by various automation we have in place.

Knock wood.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 6272cc38 16-Aug-2021 Nathan Chancellor <nathan@kernel.org>

kbuild: Shuffle blank line to improve comment meaning

-Wunused-but-set-variable and -Wunused-const-variable are both disabled
for the same reason but there is a blank line between them and no blank
line between -Wno-unused-const-variable and the block.

Shuffle the new line so that it is clear that the comment applied to
both flags and the next block is separate from them.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 5c6ae0ef 16-Aug-2021 Nathan Chancellor <nathan@kernel.org>

kbuild: Add a comment above -Wno-gnu

Whenever a warning is disabled, it is helpful for future travelers to
understand why the warning is disabled and why it is acceptable to do
so. Add a comment for -Wno-gnu so that people understand why it is
disabled.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a312b60d 16-Aug-2021 Nathan Chancellor <nathan@kernel.org>

kbuild: Remove -Wno-format-invalid-specifier from clang block

Turning on -Wformat does not reveal any instances of this warning across
several different builds so remove this line to keep the number of
disabled warnings as slim as possible.

This has been disabled since commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang"), which does not
explain exactly why it was turned off but since it was so long ago in
terms of both the kernel and LLVM so it is possible that some bug got
fixed along the way.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 7d73c3e9 16-Aug-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: remove stale cc-option checks

cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.

The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack

The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds

The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH

-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.

--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.

-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.

Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 52cc02b9 05-Aug-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS

LLVM_IAS is the user interface to set the -(no-)integrated-as flag,
and it should be used only for that purpose.

LLVM_IAS is checked in some places to determine the assembler type,
but it is not precise.

For example,

$ make CC=gcc LLVM_IAS=1

... will use the GNU assembler (i.e. binutils) since LLVM_IAS=1 is
effective only when $(CC) is clang.

Of course, 'CC=gcc LLVM_IAS=1' is an odd combination, but the build
system can be more robust against such insane input.

Commit ba64beb17493a ("kbuild: check the minimum assembler version in
Kconfig") introduced CONFIG_AS_IS_GNU/LLVM, which is more precise
because Kconfig checks the version string from the assembler in use.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>


# 6f5b41a2 02-Aug-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: move initial clang flag handling into scripts/Makefile.clang

With some of the changes we'd like to make to CROSS_COMPILE, the initial
block of clang flag handling which controls things like the target triple,
whether or not to use the integrated assembler and how to find GAS,
and erroring on unknown warnings is becoming unwieldy. Move it into its
own file under scripts/.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 6072b2c4 31-Jul-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: warn if a different compiler is used for external module builds

It is always safe to use the same compiler for the kernel and external
modules, but in reality, some distributions such as Fedora release a
different version of GCC from the one used for building the kernel.

There was a long discussion about mixing different compilers [1].

I do not repeat it here, but at least, showing a heads up in that
case is better than nothing.

Linus suggested [2]:
And a warning might be more palatable even if different compiler
version work fine together. Just a heads up on "it looks like you
might be mixing compiler versions" is a valid note, and isn't
necessarily wrong. Even when they work well together, maybe you want
to have people at least _aware_ of it.

This commit shows a warning unless the compiler is exactly the same.

warning: the compiler differs from the one used to build the kernel
The kernel was built by: gcc (GCC) 11.1.1 20210531 (Red Hat 11.1.1-3)
You are using: gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)

Check the difference, and if it is OK with you, please proceed at your
risk.

To avoid the locale issue as in commit bcbcf50f5218 ("kbuild: fix
ld-version.sh to not be affected by locale"), pass LC_ALL=C to
"$(CC) --version".

[1] https://lore.kernel.org/linux-hardening/efe6b039a544da8215d5e54aa7c4b6d1986fc2b0.1611607264.git.jpoimboe@redhat.com/
[2] https://lore.kernel.org/lkml/CAHk-=wgjwhDy-y4mQh34L+2aF=n6BjzHdqAW2=8wri5x7O04pA@mail.gmail.com/

Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# d8285639 24-Jul-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: do not require sub-make for separate output tree builds

As explained in commit 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some
included Makefiles"), I want to stop using --include-dir some day.

I already fixed up the top Makefile, but some arch Makefiles (mips, um,
x86) still include check-in Makefiles without $(srctree)/.

Fix them up so 'need-sub-make := 1' can go away for this case.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 5f6e0fe0 09-Jun-2021 Masahiro Yamada <masahiroy@kernel.org>

parisc: Fix compile failure when building 64-bit kernel natively

Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is
a cross build or not") broke 64-bit parisc builds on 32-bit parisc
systems.

Helge mentioned:
- 64-bit parisc userspace is not supported yet [1]
- hppa gcc does not support "-m64" flag [2]

That means, parisc developers working on a 32-bit parisc machine need
to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit
parisc kernel.

After the offending commit, gcc is used in such a case because
both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is
unset.

A correct way is to introduce ARCH=parisc64 because building the 64-bit
parisc kernel on a 32-bit parisc system is not exactly a native build,
but rather a semi-cross build.

[1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t
[2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/

Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Cc: <stable@vger.kernel.org> # v5.13+
Signed-off-by: Helge Deller <deller@gmx.de>


# a82adfd5 12-Apr-2021 Kees Cook <keescook@chromium.org>

hardening: Introduce CONFIG_ZERO_CALL_USED_REGS

When CONFIG_ZERO_CALL_USED_REGS is enabled, build the kernel with
"-fzero-call-used-regs=used-gpr" (in GCC 11). This option will zero any
caller-used register contents just before returning from a function,
ensuring that temporary values are not leaked beyond the function
boundary. This means that register contents are less likely to be
available for side channel attacks and information exposures.

Additionally this helps reduce the number of useful ROP gadgets in the
kernel image by about 20%:

$ ROPgadget.py --nosys --nojop --binary vmlinux.stock | tail -n1
Unique gadgets found: 337245

$ ROPgadget.py --nosys --nojop --binary vmlinux.zero-call-regs | tail -n1
Unique gadgets found: 267175

and more notably removes simple "write-what-where" gadgets:

$ ROPgadget.py --ropchain --binary vmlinux.stock | sed -n '/Step 1/,/Step 2/p'
- Step 1 -- Write-what-where gadgets

[+] Gadget found: 0xffffffff8102d76c mov qword ptr [rsi], rdx ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff8104d7c8 pop rdx ; ret
[-] Can't find the 'xor rdx, rdx' gadget. Try with another 'mov [reg], reg'

[+] Gadget found: 0xffffffff814c2b4c mov qword ptr [rsi], rdi ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81001e51 pop rdi ; ret
[-] Can't find the 'xor rdi, rdi' gadget. Try with another 'mov [reg], reg'

[+] Gadget found: 0xffffffff81540d61 mov qword ptr [rsi], rdi ; pop rbx ; pop rbp ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81001e51 pop rdi ; ret
[-] Can't find the 'xor rdi, rdi' gadget. Try with another 'mov [reg], reg'

[+] Gadget found: 0xffffffff8105341e mov qword ptr [rsi], rax ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81029a11 pop rax ; ret
[+] Gadget found: 0xffffffff811f1c3b xor rax, rax ; ret

- Step 2 -- Init syscall number gadgets

$ ROPgadget.py --ropchain --binary vmlinux.zero* | sed -n '/Step 1/,/Step 2/p'
- Step 1 -- Write-what-where gadgets

[-] Can't find the 'mov qword ptr [r64], r64' gadget

For an x86_64 parallel build tests, this has a less than 1% performance
impact, and grows the image size less than 1%:

$ size vmlinux.stock vmlinux.zero-call-regs
text data bss dec hex filename
22437676 8559152 14127340 45124168 2b08a48 vmlinux.stock
22453184 8563248 14110956 45127388 2b096dc vmlinux.zero-call-regs

Impact for other architectures may vary. For example, arm64 sees a 5.5%
image size growth, mainly due to needing to always clear x16 and x17:
https://lore.kernel.org/lkml/20210510134503.GA88495@C02TD0UTHF1T.local/

Signed-off-by: Kees Cook <keescook@chromium.org>


# 7d2a07b7 29-Aug-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14


# e22ce8eb 22-Aug-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc7


# 7c60610d 15-Aug-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc6


# 36a21d51 08-Aug-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc5


# 14ccc638 28-Jul-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: cancel sub_make_done for the install target to fix DKMS

Since commit bcf637f54f6d ("kbuild: parse C= and M= before changing the
working directory"), external module builds invoked by DKMS fail because
M= option is not parsed.

I wanted to add 'unset sub_make_done' in install.sh but similar scripts,
arch/*/boot/install.sh, are duplicated, so I set sub_make_done empty in
the top Makefile.

Fixes: bcf637f54f6d ("kbuild: parse C= and M= before changing the working directory")
Reported-by: John S Gruber <johnsgruber@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: John S Gruber <johnsgruber@gmail.com>


# b18b851b 02-Aug-2021 Nathan Chancellor <nathan@kernel.org>

scripts/recordmcount.pl: Remove check_objcopy() and $can_use_local

When building ARCH=riscv allmodconfig with llvm-objcopy, the objcopy
version warning from this script appears:

WARNING: could not find objcopy version or version is less than 2.17.
Local function references are disabled.

The check_objcopy() function in scripts/recordmcount.pl is set up to
parse GNU objcopy's version string, not llvm-objcopy's, which triggers
the warning.

Commit 799c43415442 ("kbuild: thin archives make default for all archs")
made binutils 2.20 mandatory and commit ba64beb17493 ("kbuild: check the
minimum assembler version in Kconfig") enforces this at configuration
time so just remove check_objcopy() and $can_use_local instead, assuming
--globalize-symbol is always available.

llvm-objcopy has supported --globalize-symbol since LLVM 7.0.0 in 2018
and the minimum version for building the kernel with LLVM is 10.0.1 so
there is no issue introduced:

Link: https://github.com/llvm/llvm-project/commit/ee5be798dae30d5f9414b01f76ff807edbc881aa
Link: https://lkml.kernel.org/r/20210802210307.3202472-1-nathan@kernel.org

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


# c500bee1 01-Aug-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc4


# ff117646 25-Jul-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc3


# 2734d6c1 18-Jul-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc2


# d952cfaf 13-Jul-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: do not suppress Kconfig prompts for silent build

When a new CONFIG option is available, Kbuild shows a prompt to get
the user input.

$ make
[ snip ]
Core Scheduling for SMT (SCHED_CORE) [N/y/?] (NEW)

This is the only interactive place in the build process.

Commit 174a1dcc9642 ("kbuild: sink stdout from cmd for silent build")
suppressed Kconfig prompts as well because syncconfig is invoked by
the 'cmd' macro. You cannot notice the fact that Kconfig is waiting
for the user input.

Use 'kecho' to show the equivalent short log without suppressing stdout
from sub-make.

Fixes: 174a1dcc9642 ("kbuild: sink stdout from cmd for silent build")
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>


# d936eb23 15-Jul-2021 Linus Torvalds <torvalds@linux-foundation.org>

Revert "Makefile: Enable -Wimplicit-fallthrough for Clang"

This reverts commit b7eb335e26a9c7f258c96b3962c283c379d3ede0.

It turns out that the problem with the clang -Wimplicit-fallthrough
warning is not about the kernel source code, but about clang itself, and
that the warning is unusable until clang fixes its broken ways.

In particular, when you enable this warning for clang, you not only get
warnings about implicit fallthroughs. You also get this:

warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

which is completely broken becasue it

(a) doesn't even tell you where the problem is (seriously: no line
numbers, no filename, no nothing).

(b) is fundamentally broken anyway, because there are perfectly valid
reasons to have a fallthrough statement even if it turns out that
it can perhaps not be reached.

In the kernel, an example of that second case is code in the scheduler:

switch (state) {
case cpuset:
if (IS_ENABLED(CONFIG_CPUSETS)) {
cpuset_cpus_allowed_fallback(p);
state = possible;
break;
}
fallthrough;
case possible:

where if CONFIG_CPUSETS is enabled you actually never hit the
fallthrough case at all. But that in no way makes the fallthrough
wrong.

So the warning is completely broken, and enabling it for clang is a very
bad idea.

In the meantime, we can keep the gcc option enabled, and make the gcc
build use

-Wimplicit-fallthrough=5

which means that we will at least continue to require a proper
fallthrough statement, and that gcc won't silently accept the magic
comment versions. Because gcc does this all correctly, and while the odd
"=5" part is kind of obscure, it's documented in [1]:

"-Wimplicit-fallthrough=5 doesn’t recognize any comments as
fallthrough comments, only attributes disable the warning"

so if clang ever fixes its bad behavior we can try enabling it there again.

Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [1]
Cc: Kees Cook <keescook@chromium.org>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# b7eb335e 11-Jul-2021 Gustavo A. R. Silva <gustavoars@kernel.org>

Makefile: Enable -Wimplicit-fallthrough for Clang

With the recent fixes for fallthrough warnings, it is now possible to
enable -Wimplicit-fallthrough for Clang.

It's important to mention that since we have adopted the use of the
pseudo-keyword macro fallthrough; we also want to avoid having more
/* fall through */ comments being introduced. Notice that contrary
to GCC, Clang doesn't recognize any comments as implicit fall-through
markings when the -Wimplicit-fallthrough option is enabled. So, in
order to avoid having more comments being introduced, we have to use
the option -Wimplicit-fallthrough=5 for GCC, which similar to Clang,
will cause a warning in case a code comment is intended to be used
as a fall-through marking.

Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>


# e73f0f0e 11-Jul-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.14-rc1


# 74ee585b 02-Jun-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove trailing slashes from $(KBUILD_EXTMOD)

M= (or KBUILD_EXTMOD) generally expects a directory path without any
trailing slashes, like M=a/b/c.

If you add a trailing slash, like M=a/b/c/, you will get ugly build
logs (two slashes in a series), but it still works fine as long as it
is consistent between 'make modules' and 'make modules_install'.

The following commands correctly build and install the modules.

$ make M=a/b/c/ modules
$ sudo make M=a/b/c/ modules_install

Since commit ccae4cfa7bfb ("kbuild: refactor scripts/Makefile.modinst"),
a problem happens if you add a trailing slash only for modules_install.

$ make M=a/b/c modules
$ sudo make M=a/b/c/ modules_install

No module is installed in this case, Johannes Berg reported. [1]

Trim any trailing slashes from $(KBUILD_EXTMOD).

I used the 'dirname' command to remove all the trailing slashes in
case someone adds more slashes like M=a/b/c/////. The Make's built-in
function, $(dir ...) cannot take care of such a case.

[1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/

Fixes: ccae4cfa7bfb ("kbuild: refactor scripts/Makefile.modinst")
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 2728fcfa 17-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: merge scripts/mkmakefile to top Makefile

scripts/mkmakefile is simple enough to be merged in the Makefile.

Use $(call cmd,...) to show the log instead of doing it in the
shell script.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# d92cc4d5 12-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: require all architectures to have arch/$(SRCARCH)/Kbuild

arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can
use the obj-y syntax.

Add an empty file if it is missing in arch/$(SRCARCH)/.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 0d989ac2 12-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove libelf checks from top Makefile

I do not see a good reason why only the libelf development package must
be so carefully checked.

Kbuild generally does not check host tools or libraries.

For example, x86_64 defconfig fails to build with no libssl development
package installed.

scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or directory
21 | #include <openssl/bio.h>
| ^~~~~~~~~~~~~~~

To solve the build error, you need to install libssl-dev or openssl-devel
package, depending on your distribution.

'apt-file search', 'dnf provides', etc. is your frined to find a proper
package to install.

This commit removes all the libelf checks from the top Makefile.

If libelf is missing, objtool will fail to build in a similar pattern:

.../linux/tools/objtool/include/objtool/elf.h:10:10: fatal error: gelf.h: No such file or directory
10 | #include <gelf.h>

You need to install libelf-dev, libelf-devel, or elfutils-libelf-devel
to proceed.

Another remarkable change is, CONFIG_STACK_VALIDATION (without
CONFIG_UNWINDER_ORC) previously continued to build with a warning,
but now it will treat missing libelf as an error.

This is just a one-time installation, so it should not hurt to break
a build and make a user install the package.

BTW, the traditional way to handle such checks is autotool, but according
to [1], I do not expect the kernel build would have similar scripting
like './configure' does.

[1]: https://lore.kernel.org/lkml/CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com/

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>


# 1bb0b18a 12-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: hide tools/ build targets from external module builds

The tools/ directory only exists in the kernel source tree, not in
external modules.

Do not expose the meaningless targets to external modules.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# cf536e18 06-May-2021 Feng Tang <feng.tang@intel.com>

Makefile: extend 32B aligned debug option to 64B aligned

Commit 09c60546f04f ("./Makefile: add debug option to enable
function aligned on 32 bytes") was introduced to help debugging
strange kernel performance changes caused by code alignment
change.

Recently we found 2 similar cases [1][2] caused by code-alignment
changes, which can only be identified by forcing 64 bytes aligned
for all functions.

Originally, 32 bytes was used mainly for not wasting too much
text space, but this option is only for debug anyway where text
space is not a big concern. So extend the alignment to 64 bytes
to cover more similar cases.

[1].https://lore.kernel.org/lkml/20210427090013.GG32408@xsang-OptiPlex-9020/
[2].https://lore.kernel.org/lkml/20210420030837.GB31773@xsang-OptiPlex-9020/
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 27f2a4db 21-May-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: fix GDB warning with CONFIG_RELR

GDB produces the following warning when debugging kernels built with
CONFIG_RELR:

BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'

when loading a kernel built with CONFIG_RELR into GDB. It can also
prevent debugging symbols using such relocations.

Peter sugguests:
[That flag] means that lld will use dynamic tags and section type
numbers in the OS-specific range rather than the generic range. The
kernel itself doesn't care about these numbers; it determines the
location of the RELR section using symbols defined by a linker script.

Link: https://github.com/ClangBuiltLinux/linux/issues/1057
Suggested-by: Peter Collingbourne <pcc@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com
Signed-off-by: Will Deacon <will@kernel.org>


# 62fb9874 27-Jun-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13


# 13311e74 20-Jun-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc7


# 0236526d 13-Jun-2021 Tor Vic <torvic9@mailbox.org>

Makefile: lto: Pass -warn-stack-size only on LLD < 13.0.0

Since LLVM commit fc018eb, the '-warn-stack-size' flag has been dropped
[1], leading to the following error message when building with Clang-13
and LLD-13:

ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument
'-warn-stack-size=2048'. Try: 'ld.lld --help'
ld.lld: Did you mean '--asan-stack=2048'?

In the same way as with commit 2398ce80152a ("x86, lto: Pass
-stack-alignment only on LLD < 13.0.0") , make '-warn-stack-size'
conditional on LLD < 13.0.0.

[1] https://reviews.llvm.org/D103928

Fixes: 24845dcb170e ("Makefile: LTO: have linker check -Wframe-larger-than")
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1377
Signed-off-by: Tor Vic <torvic9@mailbox.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/7631bab7-a8ab-f884-ab54-f4198976125c@mailbox.org


# 009c9aa5 13-Jun-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc6


# 614124be 06-Jun-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc5


# 8124c8a6 30-May-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc4


# 24845dcb 11-Mar-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: LTO: have linker check -Wframe-larger-than

-Wframe-larger-than= requires stack frame information, which the
frontend cannot provide. This diagnostic is emitted late during
compilation once stack frame size is available.

When building with LTO, the frontend simply lowers C to LLVM IR and does
not have stack frame information, so it cannot emit this diagnostic.
When the linker drives LTO, it restarts optimizations and lowers LLVM IR
to object code. At that point, it has stack frame information but
doesn't know to check for a specific max stack frame size.

I consider this a bug in LLVM that we need to fix. There are some
details we're working out related to LTO such as which value to use when
there are multiple different values specified per TU, or how to
propagate these to compiler synthesized routines properly, if at all.

Until it's fixed, ensure we don't miss these. At that point we can wrap
this in a compiler version guard or revert this based on the minimum
support version of Clang.

The error message is not generated during link:
LTO vmlinux.o
ld.lld: warning: stack size limit exceeded (8224) in foobarbaz

Cc: Sami Tolvanen <samitolvanen@google.com>
Reported-by: Candle Sun <candlesea@gmail.com>
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com


# c4681547 23-May-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc3


# d07f6ca9 16-May-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc2


# 6efb943b 09-May-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.13-rc1


# 11122b86 04-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove the unneeded comments for external module builds

The supported targets for external modules are listed in the help target
a few lines below. Let's not have duplicated information in two places.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 7a02cec5 04-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make distclean remove tag files in sub-directories

'make tags' and friends create tag files in the top directory, but
people may manually create tag files in sub-directories.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 19c8d912 04-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make distclean work against $(objtree) instead of $(srctree)

This reverts the old commit [1], which seems questionable to me.

It claimed 'make distclean' could not remove editor backup files,
but I believe KBUILD_OUTPUT or O= was set.

When O= is given, Kbuild should always work against $(objtree).
If O= is not given, $(objtree) and $(srctree) are the same, therefore
$(srctree) is cleaned up.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=dd47df980c02eb33833b2690b033c34fba2fa80d

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 45799491 01-May-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove ARCH=sh64 support from top Makefile

Commit 37744feebc08 ("sh: remove sh5 support") removed the SUPERH64
support entirely.

Remove the left-over code from the top Makefile.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>


# 885480b0 28-Apr-2021 Nathan Chancellor <nathan@kernel.org>

Makefile: Move -Wno-unused-but-set-variable out of GCC only block

Currently, -Wunused-but-set-variable is only supported by GCC so it is
disabled unconditionally in a GCC only block (it is enabled with W=1).
clang currently has its implementation for this warning in review so
preemptively move this statement out of the GCC only block and wrap it
with cc-disable-warning so that both compilers function the same.

Cc: stable@vger.kernel.org
Link: https://reviews.llvm.org/D100581
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 1476fee5 25-Apr-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add a script to remove stale generated files

We maintain .gitignore and Makefiles so build artifacts are properly
ignored by Git, and cleaned up by 'make clean'. However, the code is
always changing; generated files are often moved to another directory,
or removed when they become unnecessary. Such garbage files tend to be
left over in the source tree because people usually git-pull without
cleaning the tree.

This is not only the noise for 'git status', but also a build issue
in some cases.

One solution is to remove a stale file like commit 223c24a7dba9 ("kbuild:
Automatically remove stale <linux/version.h> file") did. Such workaround
should be removed after a while, but we forget about that if we scatter
the workaround code in random places.

So, this commit adds a new script to collect cleanings of stale files.

As a start point, move the code in arch/arm/boot/compressed/Makefile
into this script.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b31f2a49 09-Apr-2021 Nayna Jain <nayna@linux.ibm.com>

keys: cleanup build time module signing keys

The "mrproper" target is still looking for build time generated keys in
the kernel root directory instead of certs directory. Fix the path and
remove the names of the files which are no longer generated.

Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>


# f634ca65 22-Apr-2021 Nathan Chancellor <nathan@kernel.org>

kbuild: Add $(KBUILD_HOSTLDFLAGS) to 'has_libelf' test

Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which
in turn includes $(HOSTLDFLAGS), which allows users to pass in their own
flags when linking. However, the 'has_libelf' test does not, meaning
that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=...,
it is not respected and the build might error.

For example, if a user building with clang wants to use all of the LLVM
tools without any GNU tools, they might remove all of the GNU tools from
their system or PATH then build with

$ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1

which says use all of the LLVM tools, the integrated assembler, and
ld.lld for linking host executables. Without this change, the build will
error because $(HOSTCC) uses its default linker, rather than the one
requested via -fuse-ld=..., which is GNU ld in clang's case in a default
configuration.

error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
install libelf-dev, libelf-devel or elfutils-libelf-devel
make[1]: *** [Makefile:1260: prepare-objtool] Error 1

Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker
choice is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/479
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 961ab4a3 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst

scripts/Makefile.modsign is a subset of scripts/Makefile.modinst,
and duplicates the code. Let's merge them.

By the way, you do not need to run 'make modules_sign' explicitly
because modules are signed as a part of 'make modules_install' when
CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is
set to 'true', so 'make modules_sign' is not functional.

In my understanding, the reason of still keeping this is to handle
corner cases like commit 64178cb62c32 ("builddeb: fix stripped module
signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set").

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 65ce9c38 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: move module strip/compression code into scripts/Makefile.modinst

Both mod_strip_cmd and mod_compress_cmd are only used in
scripts/Makefile.modinst, hence there is no good reason to define them
in the top Makefile. Move the relevant code to scripts/Makefile.modinst.

Also, show separate log messages for each of install, strip, sign, and
compress.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# ccae4cfa 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: refactor scripts/Makefile.modinst

scripts/Makefile.modinst is ugly and weird in multiple ways; it
specifies real files $(modules) as phony, makes directory manipulation
needlessly too complicated.

Clean up the Makefile code, and show the full path of installed modules
in the log.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 7f69180b 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: rename extmod-prefix to extmod_prefix

This seems to be useful in sub-make as well. As a preparation of
exporting it, rename extmod-prefix to extmod_prefix because exported
variables cannot contain hyphens.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 1a998be6 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: check module name conflict for external modules as well

If there are multiple modules with the same name in the same external
module tree, there is ambiguity about which one will be loaded, and
very likely something odd is happening.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3ac42b21 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: show the target directory for depmod log

It is clearer to show the directory which depmod will work on.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3e3005df 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: unify modules(_install) for in-tree and external modules

If you attempt to build or install modules ('make modules(_install)'
with CONFIG_MODULES disabled, you will get a clear error message, but
nothing for external module builds.

Factor out the modules and modules_install rules into the common part,
so you will get the same error message when you try to build external
modules with CONFIG_MODULES=n.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 4b97ec0e 31-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove unneeded mkdir for external modules_install

scripts/Makefile.modinst creates directories as needed.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 69bc8d38 25-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: generate Module.symvers only when vmlinux exists

The external module build shows the following warning if Module.symvers
is missing in the kernel tree.

WARNING: Symbol version dump "Module.symvers" is missing.
Modules may not have dependencies or modversions.

I think this is an important heads-up because the resulting modules may
not work as expected. This happens when you did not build the entire
kernel tree, for example, you might have prepared the minimal setups
for external modules by 'make defconfig && make modules_preapre'.

A problem is that 'make modules' creates Module.symvers even without
vmlinux. In this case, that warning is suppressed since Module.symvers
already exists in spite of its incomplete content.

The incomplete (i.e. invalid) Module.symvers should not be created.

This commit changes the second pass of modpost to dump symbols into
modules-only.symvers. The final Module.symvers is created by
concatenating vmlinux.symvers and modules-only.symvers if both exist.

Module.symvers is supposed to collect symbols from both vmlinux and
modules. It might be a bit confusing, and I am not quite sure if it
is an official interface, but presumably it is difficult to rename it
because some tools (e.g. kmod) parse it.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# ba64beb1 15-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: check the minimum assembler version in Kconfig

Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.

Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.

Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.

As usual, the --version option prints the version string.

$ as --version | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1

But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.

$ gcc -Wa,--version | head -n 1
gcc: fatal error: no input files
compilation terminated.

OK, we need to input something to satisfy gcc.

$ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1

The combination of Clang and GNU assembler works in the same way:

$ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1

Clang with the integrated assembler fails like this:

$ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
clang: error: unsupported argument '--version' to option 'Wa,'

For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.

One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.

Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]

With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.

$ scripts/as-version.sh gcc
GNU 23501
$ scripts/as-version.sh clang -no-integrated-as
GNU 23501
$ scripts/as-version.sh clang -integrated-as
LLVM 0

[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>


# 6e0839fd 13-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: replace sed with $(subst ) or $(patsubst )

For simple text replacement, it is better to use a built-in function
instead of sed if possible. You can save one process forking.

I do not mean to replace all sed invocations because GNU Make itself
does not support regular expression (unless you use guile).

I just replaced simple ones.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# eec08090 09-Mar-2021 Nathan Chancellor <nathan@kernel.org>

Makefile: Only specify '--prefix=' when building with clang + GNU as

When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find GNU cross tools,
which will not be used indirectly when using the integrated assembler.
All of the tools are invoked directly from PATH or a full path specified
via the command line, which does not depend on the value of '--prefix='.

Sharing commands to reproduce issues becomes a little bit easier without
a '--prefix=' value because that '--prefix=' value is specific to a
user's machine due to it being an absolute path.

Some further notes from Fangrui Song:

clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
objcopy is only used for GNU as assembled object files.
With integrated assembler, the object file streamer creates .o and
.dwo simultaneously.
With GNU as, two objcopy commands are needed to extract .debug*.dwo to
.dwo files && another command to remove .debug*.dwo sections.

A small consequence of this change (to keep things simple) is that
'--prefix=' will always be specified now, even with a native build, when
it was not before. This should not be an issue due to the way that the
Makefile searches for the prefix (based on elfedit's location). This
ends up improving the experience for host builds because PATH is better
respected and matches GCC's behavior more closely. See the below thread
for more details:

https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# c91d4e47 09-Mar-2021 Nathan Chancellor <nathan@kernel.org>

Makefile: Remove '--gcc-toolchain' flag

This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa595b ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9db80 ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.

This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.

Link: https://reviews.llvm.org/D97902
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 0b956e20 05-Mar-2021 Rasmus Villemoes <linux@rasmusvillemoes.dk>

kbuild: apply fixdep logic to link-vmlinux.sh

The patch adding CONFIG_VMLINUX_MAP revealed a small defect in the
build system: link-vmlinux.sh takes decisions based on CONFIG_*
options, but changing one of those does not always lead to vmlinux
being linked again.

For most of the CONFIG_* knobs referenced previously, this has
probably been hidden by those knobs also affecting some object file,
hence indirectly also vmlinux.

But CONFIG_VMLINUX_MAP is only handled inside link-vmlinux.sh, and
changing CONFIG_VMLINUX_MAP=n to CONFIG_VMLINUX_MAP=y does not cause
the build system to re-link (and hence have vmlinux.map
emitted). Since that map file is mostly a debugging aid, this is
merely a nuisance which is easily worked around by just deleting
vmlinux and building again.

But one could imagine other (possibly future) CONFIG options that
actually do affect the vmlinux binary but which are not captured
through some object file dependency.

To fix this, make link-vmlinux.sh emit a .vmlinux.d file in the same
format as the dependency files generated by gcc, and apply the fixdep
logic to that. I've tested that this correctly works with both in-tree
and out-of-tree builds.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 609bbb4d 02-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: show warning if 'make headers_check' is used

Since commit 7ecaf069da52 ("kbuild: move headers_check rule to
usr/include/Makefile"), 'make headers_check' is no-op.

This stub target is remaining here in case some scripts still invoke it.
In order to prompt people to remove stale code, show a noisy warning
message if used. The stub will be really removed after the Linux 5.15
release.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 805b2e1d 27-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: include Makefile.compiler only when compiler is needed

Since commit f2f02ebd8f38 ("kbuild: improve cc-option to clean up all
temporary files"), running 'make kernelversion' in a read-only source
tree emits a bunch of warnings:

mkdir: cannot create directory '.tmp_12345': Permission denied

No-build targets such as kernelversion, clean, help, etc. do not
need to evaluate $(call cc-option,) or friends. Skip Makefile.compiler
so $(call cc-option,) becomes no-op.

This not only fixes the warnings, but also runs non-build targets much
faster.

Basically, all installation targets should also be non-build targets.
Unfortunately, vdso_install requires the compiler because it builds
vdso before installation. This is a problem that must be fixed by a
separate patch.

Reported-by: Israel Tsadok <itsadok@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 57fd251c 27-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: split cc-option and friends to scripts/Makefile.compiler

scripts/Kbuild.include is included everywhere, but macros such as
cc-option are needed by build targets only.

For example, when 'make clean' traverses the tree, it does not need
to evaluate $(call cc-option,).

Split cc-option, ld-option, etc. to scripts/Makefile.compiler, which
is only included from the top Makefile and scripts/Makefile.build.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# f02aa48d 10-Apr-2021 Masahiro Yamada <masahiroy@kernel.org>

kconfig: use /boot/config-* etc. as DEFCONFIG_LIST only for native build

When the .config file is missing, 'make config', 'make menuconfig', etc.
uses a file listed in DEFCONFIG_LIST, if found, as base configuration.

Ususally, /boot/config-$(uname -r) exists, and is used as default.

However, when you are cross-compiling the kernel, it does not make
sense to use /boot/config-* on the build host. It should default to
arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG).

UML previously did not use DEFCONFIG_LIST at all, but it should be
able to use arch/um/configs/$(KBUILD_DEFCONFIG) as a base config file.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# dd465996 13-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kconfig: move default KBUILD_DEFCONFIG back to scripts/kconfig/Makefile

This is a partial revert of commit 2a86f6612164 ("kbuild: use
KBUILD_DEFCONFIG as the fallback for DEFCONFIG_LIST").

Now that the reference to $(DEFCONFIG_LIST) was removed from
init/Kconfig, the default KBUILD_DEFCONFIG can go back home.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3204a7fb 27-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: prefix $(srctree)/ to some included Makefiles

VPATH is used in Kbuild to make pattern rules search for prerequisites
in both $(objtree) and $(srctree). Some of *.c, *.S files are not real
sources, but generated by tools such as flex, bison, perl.

In contrast, I doubt the benefit of --include-dir=$(abs_srctree) because
it is always clear which Makefiles are real sources, and which are not.

So, my hope is to add $(srctree)/ prefix to all check-in Makefiles,
then remove --include-dir=$(abs_srctree) flag in the future.

I am touching only some Kbuild core parts for now. Treewide fixes will
be needed to achieve this goal.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# cf68fffb 08-Apr-2021 Sami Tolvanen <samitolvanen@google.com>

add support for Clang CFI

This change adds support for Clang’s forward-edge Control Flow
Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
injects a runtime check before each indirect function call to ensure
the target is a valid function with the correct static type. This
restricts possible call targets and makes it more difficult for
an attacker to exploit bugs that allow the modification of stored
function pointers. For more details, see:

https://clang.llvm.org/docs/ControlFlowIntegrity.html

Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
visibility to possible call targets. Kernel modules are supported
with Clang’s cross-DSO CFI mode, which allows checking between
independently compiled components.

With CFI enabled, the compiler injects a __cfi_check() function into
the kernel and each module for validating local call targets. For
cross-module calls that cannot be validated locally, the compiler
calls the global __cfi_slowpath_diag() function, which determines
the target module and calls the correct __cfi_check() function. This
patch includes a slowpath implementation that uses __module_address()
to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
shadow map that speeds up module look-ups by ~3x.

Clang implements indirect call checking using jump tables and
offers two methods of generating them. With canonical jump tables,
the compiler renames each address-taken function to <function>.cfi
and points the original symbol to a jump table entry, which passes
__cfi_check() validation. This isn’t compatible with stand-alone
assembly code, which the compiler doesn’t instrument, and would
result in indirect calls to assembly code to fail. Therefore, we
default to using non-canonical jump tables instead, where the compiler
generates a local jump table entry <function>.cfi_jt for each
address-taken function, and replaces all references to the function
with the address of the jump table entry.

Note that because non-canonical jump table addresses are local
to each component, they break cross-module function address
equality. Specifically, the address of a global function will be
different in each module, as it's replaced with the address of a local
jump table entry. If this address is passed to a different module,
it won’t match the address of the same function taken there. This
may break code that relies on comparing addresses passed from other
components.

CFI checking can be disabled in a function with the __nocfi attribute.
Additionally, CFI can be disabled for an entire compilation unit by
filtering out CC_FLAGS_CFI.

By default, CFI failures result in a kernel panic to stop a potential
exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
kernel prints out a rate-limited warning instead, and allows execution
to continue. This option is helpful for locating type mismatches, but
should only be enabled during development.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210408182843.1754385-2-samitolvanen@google.com


# 39218ff4 01-Apr-2021 Kees Cook <keescook@chromium.org>

stack: Optionally randomize kernel stack offset each syscall

This provides the ability for architectures to enable kernel stack base
address offset randomization. This feature is controlled by the boot
param "randomize_kstack_offset=on/off", with its default value set by
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.

This feature is based on the original idea from the last public release
of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt
All the credit for the original idea goes to the PaX team. Note that
the design and implementation of this upstream randomize_kstack_offset
feature differs greatly from the RANDKSTACK feature (see below).

Reasoning for the feature:

This feature aims to make harder the various stack-based attacks that
rely on deterministic stack structure. We have had many such attacks in
past (just to name few):

https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf
https://jon.oberheide.org/files/stackjacking-infiltrate11.pdf
https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html

As Linux kernel stack protections have been constantly improving
(vmap-based stack allocation with guard pages, removal of thread_info,
STACKLEAK), attackers have had to find new ways for their exploits
to work. They have done so, continuing to rely on the kernel's stack
determinism, in situations where VMAP_STACK and THREAD_INFO_IN_TASK_STRUCT
were not relevant. For example, the following recent attacks would have
been hampered if the stack offset was non-deterministic between syscalls:

https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf
(page 70: targeting the pt_regs copy with linear stack overflow)

https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
(leaked stack address from one syscall as a target during next syscall)

The main idea is that since the stack offset is randomized on each system
call, it is harder for an attack to reliably land in any particular place
on the thread stack, even with address exposures, as the stack base will
change on the next syscall. Also, since randomization is performed after
placing pt_regs, the ptrace-based approach[1] to discover the randomized
offset during a long-running syscall should not be possible.

Design description:

During most of the kernel's execution, it runs on the "thread stack",
which is pretty deterministic in its structure: it is fixed in size,
and on every entry from userspace to kernel on a syscall the thread
stack starts construction from an address fetched from the per-cpu
cpu_current_top_of_stack variable. The first element to be pushed to the
thread stack is the pt_regs struct that stores all required CPU registers
and syscall parameters. Finally the specific syscall function is called,
with the stack being used as the kernel executes the resulting request.

The goal of randomize_kstack_offset feature is to add a random offset
after the pt_regs has been pushed to the stack and before the rest of the
thread stack is used during the syscall processing, and to change it every
time a process issues a syscall. The source of randomness is currently
architecture-defined (but x86 is using the low byte of rdtsc()). Future
improvements for different entropy sources is possible, but out of scope
for this patch. Further more, to add more unpredictability, new offsets
are chosen at the end of syscalls (the timing of which should be less
easy to measure from userspace than at syscall entry time), and stored
in a per-CPU variable, so that the life of the value does not stay
explicitly tied to a single task.

As suggested by Andy Lutomirski, the offset is added using alloca()
and an empty asm() statement with an output constraint, since it avoids
changes to assembly syscall entry code, to the unwinder, and provides
correct stack alignment as defined by the compiler.

In order to make this available by default with zero performance impact
for those that don't want it, it is boot-time selectable with static
branches. This way, if the overhead is not wanted, it can just be
left turned off with no performance impact.

The generated assembly for x86_64 with GCC looks like this:

...
ffffffff81003977: 65 8b 05 02 ea 00 7f mov %gs:0x7f00ea02(%rip),%eax
# 12380 <kstack_offset>
ffffffff8100397e: 25 ff 03 00 00 and $0x3ff,%eax
ffffffff81003983: 48 83 c0 0f add $0xf,%rax
ffffffff81003987: 25 f8 07 00 00 and $0x7f8,%eax
ffffffff8100398c: 48 29 c4 sub %rax,%rsp
ffffffff8100398f: 48 8d 44 24 0f lea 0xf(%rsp),%rax
ffffffff81003994: 48 83 e0 f0 and $0xfffffffffffffff0,%rax
...

As a result of the above stack alignment, this patch introduces about
5 bits of randomness after pt_regs is spilled to the thread stack on
x86_64, and 6 bits on x86_32 (since its has 1 fewer bit required for
stack alignment). The amount of entropy could be adjusted based on how
much of the stack space we wish to trade for security.

My measure of syscall performance overhead (on x86_64):

lmbench: /usr/lib/lmbench/bin/x86_64-linux-gnu/lat_syscall -N 10000 null
randomize_kstack_offset=y Simple syscall: 0.7082 microseconds
randomize_kstack_offset=n Simple syscall: 0.7016 microseconds

So, roughly 0.9% overhead growth for a no-op syscall, which is very
manageable. And for people that don't want this, it's off by default.

There are two gotchas with using the alloca() trick. First,
compilers that have Stack Clash protection (-fstack-clash-protection)
enabled by default (e.g. Ubuntu[3]) add pagesize stack probes to
any dynamic stack allocations. While the randomization offset is
always less than a page, the resulting assembly would still contain
(unreachable!) probing routines, bloating the resulting assembly. To
avoid this, -fno-stack-clash-protection is unconditionally added to
the kernel Makefile since this is the only dynamic stack allocation in
the kernel (now that VLAs have been removed) and it is provably safe
from Stack Clash style attacks.

The second gotcha with alloca() is a negative interaction with
-fstack-protector*, in that it sees the alloca() as an array allocation,
which triggers the unconditional addition of the stack canary function
pre/post-amble which slows down syscalls regardless of the static
branch. In order to avoid adding this unneeded check and its associated
performance impact, architectures need to carefully remove uses of
-fstack-protector-strong (or -fstack-protector) in the compilation units
that use the add_random_kstack() macro and to audit the resulting stack
mitigation coverage (to make sure no desired coverage disappears). No
change is visible for this on x86 because the stack protector is already
unconditionally disabled for the compilation unit, but the change is
required on arm64. There is, unfortunately, no attribute that can be
used to disable stack protector for specific functions.

Comparison to PaX RANDKSTACK feature:

The RANDKSTACK feature randomizes the location of the stack start
(cpu_current_top_of_stack), i.e. including the location of pt_regs
structure itself on the stack. Initially this patch followed the same
approach, but during the recent discussions[2], it has been determined
to be of a little value since, if ptrace functionality is available for
an attacker, they can use PTRACE_PEEKUSR/PTRACE_POKEUSR to read/write
different offsets in the pt_regs struct, observe the cache behavior of
the pt_regs accesses, and figure out the random stack offset. Another
difference is that the random offset is stored in a per-cpu variable,
rather than having it be per-thread. As a result, these implementations
differ a fair bit in their implementation details and results, though
obviously the intent is similar.

[1] https://lore.kernel.org/kernel-hardening/2236FBA76BA1254E88B949DDB74E612BA4BC57C1@IRSMSX102.ger.corp.intel.com/
[2] https://lore.kernel.org/kernel-hardening/20190329081358.30497-1-elena.reshetova@intel.com/
[3] https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html

Co-developed-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210401232347.2791257-4-keescook@chromium.org


# 9f4ad9e4 25-Apr-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12


# bf05bf16 18-Apr-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc8


# d434405a 11-Apr-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc7


# e49d033b 04-Apr-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc6


# a5e13c6d 28-Mar-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc5


# 0d02ec6b 21-Mar-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc4


# 1e28eed1 14-Mar-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc3


# ce6ed1c4 04-Mar-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: rebuild GCC plugins when the compiler is upgraded

Linus reported a build error due to the GCC plugin incompatibility
when the compiler is upgraded. [1]

GCC plugins are tied to a particular GCC version. So, they must be
rebuilt when the compiler is upgraded.

This seems to be a long-standing flaw since the initial support of
GCC plugins.

Extend commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the
compiler is updated"), so that GCC plugins are covered by the
compiler upgrade detection.

[1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>


# 993bdde9 27-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add image_name to no-sync-config-targets

'make image_name' needs include/config/auto.conf to show the correct
output because KBUILD_IMAGE depends on CONFIG options, but should not
attempt to resync the configuration.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a38fd874 05-Mar-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc2


# fe07bfda 28-Feb-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.12-rc1


# 207da4c8 27-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL again

Commit 78d3bb4483ba ("kbuild: Fix <linux/version.h> for empty SUBLEVEL
or PATCHLEVEL") fixed the build error for empty SUBLEVEL or PATCHLEVEL
by prepending a zero.

Commit 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255") re-introduced
this issue.

This time, we cannot take the same approach because we have C code:

#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL)
#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)

Replace empty SUBLEVEL/PATCHLEVEL with a zero.

Fixes: 9b82f13e7ef3 ("kbuild: clamp SUBLEVEL to 255")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-and-tested-by: Sasha Levin <sashal@kernel.org>


# 22149454 26-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make -s option take precedence over V=1

'make -s' should be really silent. However, 'make -s V=1' prints noisy
log messages from some shell scripts.

Of course, such a combination is odd, but the build system needs to do
the right thing even if a user gives strange input.

If -s is given, KBUILD_VERBOSE should be forced to 0.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 4c7858b9 25-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: Move .thinlto-cache removal to 'make clean'

Instead of 'make distclean', 'make clean' should remove build artifacts
unneeded by external module builds. Obviously, you do not need to keep
this directory.

Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210225193912.3303604-1-masahiroy@kernel.org


# bcf637f5 21-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: parse C= and M= before changing the working directory

If Kbuild recurses to the top Makefile (for example, 'make deb-pkg'),
C= and M= are parsed over again, needlessly.

Parse them before changing the working directory. After that,
sub_make_done is set to 1, so they are parsed just once.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 30cef68d 21-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: reuse this-makefile to define abs_srctree

Move this-makefile up, and reuse it to define abs_srctree.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# c75173a2 16-Feb-2021 Nathan Chancellor <nathan@kernel.org>

Makefile: Remove # characters from compiler string

When using AMD's Optimizing C/C++ Compiler (AOCC), the build fails due
to a # character in the version string, which is interpreted as a
comment:

$ make CC=clang defconfig init/main.o
include/config/auto.conf.cmd:1374: *** invalid syntax in conditional. Stop.

$ sed -n 1374p include/config/auto.conf.cmd
ifneq "$(CC_VERSION_TEXT)" "AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85 2020_11_10) (based on LLVM Mirror.Version.11.0.0)"

Remove all # characters in the version string so that the build does not
fail unexpectedly.

Link: https://github.com/ClangBuiltLinux/linux/issues/1298
Reported-by: Michael Fuckner <michael@fuckner.net>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# db07562a 05-Feb-2021 Nick Desaulniers <ndesaulniers@google.com>

Makefile: reuse CC_VERSION_TEXT

I noticed we're invoking $(CC) via $(shell) more than once to check the
version. Let's reuse the first string captured in $CC_VERSION_TEXT.

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
[masahiro.yamada:
CC_VERSION_TEXT is assigned by = instead of :=, so this $(shell ) is
evaluated multiple times anyway. The number of $(CC) invocations will
be still the same. Replacing 'grep' with the built-in $(findstring )
will give real performance benefit.]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 88a68672 12-Feb-2021 Sasha Levin <sashal@kernel.org>

kbuild: simplify access to the kernel's version

Instead of storing the version in a single integer and having various
kernel (and userspace) code how it's constructed, export individual
(major, patchlevel, sublevel) components and simplify kernel code that
uses it.

This should also make it easier on userspace.

Signed-off-by: Sasha Levin <sashal@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 9b82f13e 05-Feb-2021 Sasha Levin <sashal@kernel.org>

kbuild: clamp SUBLEVEL to 255

Right now if SUBLEVEL becomes larger than 255 it will overflow into the
territory of PATCHLEVEL, causing havoc in userspace that tests for
specific kernel version.

While userspace code tests for MAJOR and PATCHLEVEL, it doesn't test
SUBLEVEL at any point as ABI changes don't happen in the context of
stable tree.

Thus, to avoid overflows, simply clamp SUBLEVEL to it's maximum value in
the context of LINUX_VERSION_CODE. This does not affect "make
kernelversion" and such.

Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 98cd6f52 05-Feb-2021 Nick Desaulniers <ndesaulniers@google.com>

Kconfig: allow explicit opt in to DWARF v5

DWARF v5 is the latest standard of the DWARF debug info format. GCC 11
will change the implicit default DWARF version, if left unspecified, to
DWARF v5.

Allow users of Clang and older versions of GCC that have not changed the
implicit default DWARF version to DWARF v5 to opt in. This can help
testing consumers of DWARF debug info in preparation of v5 becoming more
widespread, as well as result in significant binary size savings of the
pre-stripped vmlinux image.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M vmlinux.clang12.dwarf5.compressed
434M vmlinux.clang12.dwarf4.compressed
439M vmlinux.clang12.dwarf2.compressed
457M vmlinux.clang12.dwarf5
536M vmlinux.clang12.dwarf4
548M vmlinux.clang12.dwarf2

515M vmlinux.gcc10.2.dwarf5.compressed
599M vmlinux.gcc10.2.dwarf4.compressed
624M vmlinux.gcc10.2.dwarf2.compressed
630M vmlinux.gcc10.2.dwarf5
765M vmlinux.gcc10.2.dwarf4
809M vmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
One thing is GCC DWARF-5 support, that is whether the compiler will
support -gdwarf-5 flag, and that support should be there from GCC 7
onwards.

All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
option that enabled some small DWARF subset (initially only a few
DW_LANG_* codes newly added to DWARF5 drafts). Only GCC 7 (released
after DWARF 5 has been finalized) started emitting DWARF5 section
headers and got most of the DWARF5 changes in...

Another separate thing is whether the assembler does support
the -gdwarf-5 option (i.e. if you can compile assembler files
with -Wa,-gdwarf-5) ... That option is about whether the assembler
will emit DWARF5 or DWARF2 .debug_line. It is fine to compile C sources
with -gdwarf-5 and use DWARF2 .debug_line for assembler files if as
doesn't support it.

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

Most issues with clang produced assembler were fixed in binutils 2.35.1,
but 2.35.2 fixed issues related to requiring the flag -Wa,-gdwarf-5
explicitly. The added shell script test checks for the latter, and is
only required when using clang without its integrated assembler, though
we use for clang regardless as we do not yet have a way to query the
assembler from Kconfig.

Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info.

This only modifies the DWARF version emitted by the compiler, not the
assembler.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump <object file> | head -n 4 | grep version
or
$ readelf --debug-dump=info <object file> 2>/dev/null | grep Version

Parts of the tree don't reuse DEBUG_CFLAGS as they should; such cleanup
is left as a follow up.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
Suggested-by: Caroline Tice <cmtice@google.com>
Suggested-by: Fangrui Song <maskray@google.com>
Suggested-by: Jakub Jelinek <jakub@redhat.com>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc1 x86-64
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a66049e2 05-Feb-2021 Nick Desaulniers <ndesaulniers@google.com>

Kbuild: make DWARF version a choice

Adds a default CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT which allows
the implicit default version of DWARF emitted by the toolchain to
progress over time.

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice, making it
mutually exclusive with CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT. Users
may want to select this if they are using a newer toolchain, but have
consumers of the DWARF debug info that aren't yet ready for newer DWARF
versions' debug info.

Does so in a way that's forward compatible with existing
configs, and makes adding future versions more straightforward. This
patch does not change the current behavior or selection of DWARF
version for users upgrading to kernels with this patch.

GCC since ~4.8 has defaulted to DWARF v4 implicitly, and GCC 11 has
bumped this to v5.

Remove the Kconfig help text about DWARF v4 being larger. It's
empirically false for the latest toolchains for x86_64 defconfig, has no
point of reference (I suspect it was DWARF v2 but that's stil
empirically false), and debug info size is not a qualatative measure.

Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
Suggested-by: Fangrui Song <maskray@google.com>
Suggested-by: Jakub Jelinek <jakub@redhat.com>
Suggested-by: Mark Wielaard <mark@klomp.org>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 0dd77e95 19-Jan-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: stop removing stale <linux/version.h> file

Revert commit 223c24a7dba9 ("kbuild: Automatically remove stale
<linux/version.h> file").

It was more than 6 years ago. I do not expect anybody to start
git-bisect for such a big window.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# db4632c6 16-Dec-2020 Tor Vic <torvic9@mailbox.org>

Makefile: use smaller dictionary size for xz module compression

By default, xz without parameters uses a dictionary size of 8 MB.
However, most modules are much smaller than that.
The xz manpage states that 'increasing dictionary size usually improves
compression ratio, but a dictionary bigger than the uncompressed file
is waste of memory'.
Use a dictionary size of 2 MB for module compression, resulting in
slightly higher compression speed while still maintaining a good
compression ratio.

Signed-off-by: Tor Vic <torvic9@mailbox.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 5e95325f 23-Feb-2021 Sami Tolvanen <samitolvanen@google.com>

kbuild: lto: force rebuilds when switching CONFIG_LTO

When doing non-clean builds and switching between CONFIG_LTO=n and
CONFIG_LTO=y, the build system (correctly) didn't notice that assembly
and LTO-excluded C object files were rewritten in place by objtool (to
add the .orc_unwind* sections), since their build command lines were the
same between CONFIG_LTO=y and CONFIG_LTO=n. The objtool step would fail:

vmlinux.o: warning: objtool: file already has .orc_unwind section, skipping
make: *** [Makefile:1194: vmlinux] Error 255

Avoid this by making sure the build will see a difference between an LTO
and non-LTO build (by including "-fno-lto" in KBUILD_*FLAGS). This will
get ignored when CC_FLAGS_LTO is present, and will not be included at
all when CONFIG_LTO=n.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>


# 22c8542d 25-Sep-2020 Sami Tolvanen <samitolvanen@google.com>

tracing: add support for objtool mcount

This change adds build support for using objtool to generate
__mcount_loc sections.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>


# 2b868952 21-Jan-2021 Alexander Lobakin <alobakin@pm.me>

kbuild: prevent CC_FLAGS_LTO self-bloating on recursive rebuilds

CC_FLAGS_LTO gets initialized only via +=, never with := or =.
When building with CONFIG_TRIM_UNUSED_KSYMS, Kbuild may perform
several kernel rebuilds to satisfy symbol dependencies. In this
case, value of CC_FLAGS_LTO is concatenated each time, which
triggers a full rebuild.
Initialize it with := to fix this.

Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210121184544.659998-1-alobakin@pm.me


# 22d429e7 11-Dec-2020 Sami Tolvanen <samitolvanen@google.com>

kbuild: lto: limit inlining

This change limits function inlining across translation unit boundaries
in order to reduce the binary size with LTO. The -import-instr-limit
flag defines a size limit, as the number of LLVM IR instructions, for
importing functions from other TUs, defaulting to 100.

Based on testing with arm64 defconfig, we found that a limit of 5 is a
reasonable compromise between performance and binary size, reducing the
size of a stripped vmlinux by 11%.

Suggested-by: George Burgess IV <gbiv@google.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-5-samitolvanen@google.com


# 38e89184 11-Dec-2020 Sami Tolvanen <samitolvanen@google.com>

kbuild: lto: fix module versioning

With CONFIG_MODVERSIONS, version information is linked into each
compilation unit that exports symbols. With LTO, we cannot use this
method as all C code is compiled into LLVM bitcode instead. This
change collects symbol versions into .symversions files and merges
them in link-vmlinux.sh where they are all linked into vmlinux.o at
the same time.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-4-samitolvanen@google.com


# dc5723b0 11-Dec-2020 Sami Tolvanen <samitolvanen@google.com>

kbuild: add support for Clang LTO

This change adds build system support for Clang's Link Time
Optimization (LTO). With -flto, instead of ELF object files, Clang
produces LLVM bitcode, which is compiled into native code at link
time, allowing the final binary to be optimized globally. For more
details, see:

https://llvm.org/docs/LinkTimeOptimization.html

The Kconfig option CONFIG_LTO_CLANG is implemented as a choice,
which defaults to LTO being disabled. To use LTO, the architecture
must select ARCH_SUPPORTS_LTO_CLANG and support:

- compiling with Clang,
- compiling all assembly code with Clang's integrated assembler,
- and linking with LLD.

While using CONFIG_LTO_CLANG_FULL results in the best runtime
performance, the compilation is not scalable in time or
memory. CONFIG_LTO_CLANG_THIN enables ThinLTO, which allows
parallel optimization and faster incremental builds. ThinLTO is
used by default if the architecture also selects
ARCH_SUPPORTS_LTO_CLANG_THIN:

https://clang.llvm.org/docs/ThinLTO.html

To enable LTO, LLVM tools must be used to handle bitcode files, by
passing LLVM=1 and LLVM_IAS=1 options to make:

$ make LLVM=1 LLVM_IAS=1 defconfig
$ scripts/config -e LTO_CLANG_THIN
$ make LLVM=1 LLVM_IAS=1

To prepare for LTO support with other compilers, common parts are
gated behind the CONFIG_LTO option, and LTO can be disabled for
specific files by filtering out CC_FLAGS_LTO.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-3-samitolvanen@google.com


# 3b15cdc1 11-Dec-2020 Sami Tolvanen <samitolvanen@google.com>

tracing: move function tracer options to Kconfig

Move function tracer options to Kconfig to make it easier to add
new methods for generating __mcount_loc, and to make the options
available also when building kernel modules.

Note that FTRACE_MCOUNT_USE_* options are updated on rebuild and
therefore, work even if the .config was generated in a different
environment.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-2-samitolvanen@google.com


# ce88c9c7 28-Jan-2021 Viresh Kumar <viresh.kumar@linaro.org>

kbuild: Add support to build overlays (%.dtbo)

Add support for building DT overlays (%.dtbo). The overlay's source file
will have the usual extension, i.e. .dts, though the blob will have
.dtbo extension to distinguish it from normal blobs.

Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/434ba2467dd0cd011565625aeb3450650afe0aae.1611904394.git.viresh.kumar@linaro.org


# 0e1aa629 11-Feb-2021 Jiri Olsa <jolsa@kernel.org>

kbuild: Do not clean resolve_btfids if the output does not exist

Nathan reported issue with cleaning empty build directory:

$ make -s O=build distclean
../../scripts/Makefile.include:4: *** \
O=/ho...build/tools/bpf/resolve_btfids does not exist. Stop.

The problem that tools scripts require existing output
directory, otherwise it fails.

Adding check around the resolve_btfids clean target to
ensure the output directory is in place.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/bpf/20210211124004.1144344-1-jolsa@kernel.org


# 50d3a3f8 05-Feb-2021 Jiri Olsa <jolsa@kernel.org>

kbuild: Add resolve_btfids clean to root clean target

The resolve_btfids tool is used during the kernel build,
so we should clean it on kernel's make clean.

Invoking the the resolve_btfids clean as part of root
'make clean'.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20210205124020.683286-5-jolsa@kernel.org


# 8b5f4eb3 25-Jan-2021 Masahiro Yamada <masahiroy@kernel.org>

net: move CONFIG_NET guard to top Makefile

When CONFIG_NET is disabled, nothing under the net/ directory is
compiled. Move the CONFIG_NET guard to the top Makefile so the net/
directory is entirely skipped.

When Kbuild visits net/Makefile, CONFIG_NET is obvioulsy 'y' because
CONFIG_NET is a bool option. Clean up net/Makefile.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-1-masahiroy@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>


# f40ddce8 14-Feb-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11


# 92bf2261 07-Feb-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc7


# 315da87c 03-Feb-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: fix duplicated flags in DEBUG_CFLAGS

Sedat Dilek noticed duplicated flags in DEBUG_CFLAGS when building
deb-pkg with CONFIG_DEBUG_INFO. For example, 'make CC=clang bindeb-pkg'
reproduces the issue.

Kbuild recurses to the top Makefile for some targets such as package
builds.

With commit 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments
for old GCC versions") applied, DEBUG_CFLAGS is now reset only when
CONFIG_CC_IS_GCC=y.

Fix it to reset DEBUG_CFLAGS all the time.

Fixes: 121c5d08d53c ("kbuild: Only add -fno-var-tracking-assignments for old GCC versions")
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Mark Wielaard <mark@klomp.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>


# d8d2d382 31-Jan-2021 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove PYTHON variable

Python retired in 2020, and some distributions do not provide the
'python' command any more.

As in commit 51839e29cb59 ("scripts: switch explicitly to Python 3"),
we need to use more specific 'python3' to invoke scripts even if they
are written in a way compatible with both Python 2 and 3.

This commit removes the variable 'PYTHON', and switches the existing
users to 'PYTHON3'.

BTW, PEP 394 (https://www.python.org/dev/peps/pep-0394/) is a helpful
material.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 1048ba83 31-Jan-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc6


# 20bf2b37 28-Jan-2021 Josh Poimboeuf <jpoimboe@redhat.com>

x86/build: Disable CET instrumentation in the kernel

With retpolines disabled, some configurations of GCC, and specifically
the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
to the kernel by default. That breaks certain tracing scenarios by
adding a superfluous ENDBR64 instruction before the fentry call, for
functions which can be called indirectly.

CET instrumentation isn't currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally and move it
into the x86's Makefile as CET/CFI... enablement should be a per-arch
decision anyway.

[ bp: Massage and extend commit message. ]

Fixes: 29be86d7f9cb ("kbuild: add -fcf-protection=none when using retpoline flags")
Reported-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Cc: <stable@vger.kernel.org>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble


# 6ee1d745 24-Jan-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc5


# 19c329f6 17-Jan-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc4


# 7c53f6b6 10-Jan-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc3


# e71ba945 03-Jan-2021 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc2


# 5c8fe583 27-Dec-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.11-rc1


# 436e980e 01-Dec-2020 Dominique Martinet <asmadeus@codewreck.org>

kbuild: don't hardcode depmod path

depmod is not guaranteed to be in /sbin, just let make look for
it in the path like all the other invoked programs

Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 2c85ebc5 13-Dec-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10


# 0477e928 06-Dec-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc7


# 59612b24 19-Nov-2020 Nathan Chancellor <nathan@kernel.org>

kbuild: Hoist '--orphan-handling' into Kconfig

Currently, '--orphan-handling=warn' is spread out across four different
architectures in their respective Makefiles, which makes it a little
unruly to deal with in case it needs to be disabled for a specific
linker version (in this case, ld.lld 10.0.1).

To make it easier to control this, hoist this warning into Kconfig and
the main Makefile so that disabling it is simpler, as the warning will
only be enabled in a couple places (main Makefile and a couple of
compressed boot folders that blow away LDFLAGS_vmlinx) and making it
conditional is easier due to Kconfig syntax. One small additional
benefit of this is saving a call to ld-option on incremental builds
because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.

To keep the list of supported architectures the same, introduce
CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to
gain this automatically after all of the sections are specified and size
asserted. A special thanks to Kees Cook for the help text on this
config.

Link: https://github.com/ClangBuiltLinux/linux/issues/1187
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b6505459 29-Nov-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc6


# b8a90923 09-Nov-2020 Nick Desaulniers <ndesaulniers@google.com>

Kbuild: do not emit debug info for assembly with LLVM_IAS=1

Clang's integrated assembler produces the warning for assembly files:

warning: DWARF2 only supports one section per compilation unit

If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for
assembly sources (it is still emitted for C sources). This will be
re-enabled for newer DWARF versions in a follow up patch.

Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with
LLVM=1 LLVM_IAS=1 for x86_64 and arm64.

Cc: <stable@vger.kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/716
Reported-by: Dmitry Golovin <dima@golovin.in>
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Suggested-by: Dmitry Golovin <dima@golovin.in>
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Suggested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a716bd74 02-Nov-2020 Denys Zagorui <dzagorui@cisco.com>

kbuild: use -fmacro-prefix-map for .S sources

Follow-up to commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to
make __FILE__ a relative path"). Assembler sources also use __FILE__
macro so this flag should be also applied to those sources.

Signed-off-by: Denys Zagorui <dzagorui@cisco.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 418baf2c 22-Nov-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc5


# 09162bc3 15-Nov-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc4


# f8394f23 08-Nov-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc3


# d9b5665f 23-Oct-2020 Vasily Gorbik <gor@linux.ibm.com>

kbuild: remove unused OBJSIZE

The "size" tool has been solely used by s390 to enforce .bss section usage
restrictions in early startup code. Since commit 980d5f9ab36b ("s390/boot:
enable .bss section for compressed kernel") and commit 2e83e0eb85ca
("s390: clean .bss before running uncompressed kernel") these restrictions
have been lifted for the decompressor and uncompressed kernel and the
size tool is now unused.

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3cea11cd 01-Nov-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc2


# 3650b228 25-Oct-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.10-rc1


# 121c5d08 17-Oct-2020 Mark Wielaard <mark@klomp.org>

kbuild: Only add -fno-var-tracking-assignments for old GCC versions

Some old GCC versions between 4.5.0 and 4.9.1 might miscompile code
with -fvar-tracking-assingments (which is enabled by default with -g -O2).
Commit 2062afb4f804 ("Fix gcc-4.9.0 miscompilation of load_balance()
in scheduler") added -fno-var-tracking-assignments unconditionally to
work around this. But newer versions of GCC no longer have this bug, so
only add it for versions of GCC before 5.0. This allows various tools
such as a perf probe or gdb debuggers or systemtap to resolve variable
locations using dwarf locations in more code.

Signed-off-by: Mark Wielaard <mark@klomp.org>
Acked-by: Ian Rogers <irogers@google.com>
Reviewed-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 4c207c50 13-Oct-2020 Nick Desaulniers <ndesaulniers@google.com>

Revert "kbuild: disable clang's default use of -fmerge-all-constants"

This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79.

-fno-merge-all-constants has been the default since clang-6; the minimum
supported version of clang in the kernel is clang-10 (10.0.1).

Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lkml.kernel.org/r/20200902225911.209899-3-ndesaulniers@google.com
Link: https://reviews.llvm.org/rL329300.
Link: https://github.com/ClangBuiltLinux/linux/issues/9
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 172aad81a 11-Oct-2020 Olaf Hering <olaf@aepfle.de>

kbuild: enforce -Werror=return-type

Catch errors which at least gcc tolerates by default:
warning: 'return' with no value, in function returning non-void [-Wreturn-type]

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# bbf5c979 11-Oct-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9


# 7dfbea4c 09-Oct-2020 Jacob Keller <jacob.e.keller@intel.com>

scripts: remove namespace.pl

namespace.pl is intended to help locate symbols which are defined but
are not used externally. The goal is to avoid bloat of the namespace in
the resulting kernel image.

The script relies on object data, and only finds unused symbols for the
configuration used to generate that object data. This results in a lot
of false positive warnings such as symbols only used by a single
architecture, or symbols which are used externally only under certain
configurations.

Running namespace.pl using allyesconfig, allmodconfig, and
x86_64_defconfig yields the following results:

* allmodconfig
* 11122 unique symbol names with no external reference
* 1194 symbols listed as multiply defined
* 214 symbols it can't resolve
* allyesconfig
* 10997 unique symbol names with no external reference
* 1194 symbols listed as multiply defined
* 214 symbols it can't resolve
* x86_64_defconfig
* 5757 unique symbol names with no external reference
* 528 symbols listed as multiply defined
* 154 symbols it can't resolve

The script also has no way to easily limit the scope of the checks to
a given subset of the kernel, such as only checking for symbols defined
within a module or subsystem.

Discussion on public mailing lists seems to indicate that many view the
tool output as suspect or not very useful (see discussions at [1] and
[2] for further context).

As described by Masahiro Yamada at [2], namespace.pl provides 3 types of
checks: listing multiply defined symbols, resolving external symbols,
and warnings about symbols with no reference.

The first category of issues is easily caught by the linker as any set
of multiply defined symbols should fail to link. The second category of
issues is also caught by linking, as undefined symbols would cause
issues. Even with modules, these types of issues where a module relies
on an external symbol are caught by modpost.

The remaining category of issues reported is the list of symbols with no
external reference, and is the primary motivation of this script.
However, it ought to be clear from the above examples that the output is
difficult to sort through. Even allyesconfig has ~10000 entries.

The current submit-checklist indicates that patches ought to go through
namespacecheck and fix any new issues arising. But that itself presents
problems. As described at [1], many cases of reports are due to
configuration where a function is used externally by some configuration
settings. Prominent maintainers appear to dislike changes modify code
such that symbols become static based on CONFIG_* flags ([3], and [4])

One possible solution is to adjust the advice and indicate that we only
care about the output of namespacecheck on allyesconfig or allmodconfig
builds...

However, given the discussion at [2], I suspect that few people are
actively using this tool. It doesn't have a maintainer in the
MAINTAINERS flie, and it produces so many warnings for unused symbols
that it is difficult to use effectively. Thus, I propose we simply
remove it.

[1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/
[2] https://lore.kernel.org/lkml/20190129204319.15238-1-jacob.e.keller@intel.com/
[3] https://lore.kernel.org/netdev/20190828.154744.2058157956381129672.davem@davemloft.net/
[4] https://lore.kernel.org/netdev/20190827210928.576c5fef@cakuba.netronome.com/

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a9684337 22-Sep-2020 Bill Wendling <morbo@google.com>

kbuild: explicitly specify the build id style

ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
The build IDs are very different between the two, which may confuse
programs that reference them.

Signed-off-by: Bill Wendling <morbo@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 549738f1 04-Oct-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc8


# a1b8638b 27-Sep-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc7


# 87de84c9 10-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove cc-option test of -Werror=date-time

The minimal compiler versions, GCC 4.9 and Clang 10 support this flag.

Here is the godbolt:
https://godbolt.org/z/xvjcMa

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Will Deacon <will@kernel.org>


# 7d4eb0d8 10-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove cc-option test of -fno-stack-check

The minimal compiler version, GCC 4.9 supports this flag.

Nathan Chancellor pointed out:
"This flag is technically ignored by clang (see commit
05b0798916f01690b5903302e51f3136274e291f) but that obviously
does not matter for the sake of this."

Here is the godbolt:
https://godbolt.org/z/59cK6o

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>


# 8b42cf2f 10-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove cc-option test of -fno-strict-overflow

The minimal compiler versions, GCC 4.9 and Clang 10 support this flag.

Here is the godbolt:
https://godbolt.org/z/odq8h9

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Will Deacon <will@kernel.org>


# bb273211 10-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: move CFLAGS_{KASAN,UBSAN,KCSAN} exports to relevant Makefiles

Move CFLAGS_KASAN*, CFLAGS_UBSAN, CFLAGS_KCSAN to Makefile.kasan,
Makefile.ubsan, Makefile.kcsan, respectively.

This commit also avoids the same -fsanitize=* flags being added to
CFLAGS_UBSAN multiple times.

Prior to this commit, the ubsan flags were appended by the '+='
operator, without any initialization. Some build targets such as
'make bindeb-pkg' recurses to the top Makefile, and ended up with
adding the same flags to CFLAGS_UBSAN twice.

Clear CFLAGS_UBSAN with ':=' to make it a simply expanded variable.
This is better than a recursively expanded variable, which evaluates
$(call cc-option, ...) multiple times before Kbuild starts descending
to subdirectories.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Marco Elver <elver@google.com>


# 6212804f 08-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: do not create built-in objects for external module builds

'make M=/path/to/your/external/module' creates a pointless built-in.a
in the top of the external module directory because KBUILD_BUILTIN is
set to 1.

Clear KBUILD_BUILTIN when we are building external modules so that
'make M=...' and 'make M=... modules' work equivalently.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 596b0474 07-Sep-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: preprocess module linker script

There was a request to preprocess the module linker script like we
do for the vmlinux one. (https://lkml.org/lkml/2020/8/21/512)

The difference between vmlinux.lds and module.lds is that the latter
is needed for external module builds, thus must be cleaned up by
'make mrproper' instead of 'make clean'. Also, it must be created
by 'make modules_prepare'.

You cannot put it in arch/$(SRCARCH)/kernel/, which is cleaned up by
'make clean'. I moved arch/$(SRCARCH)/kernel/module.lds to
arch/$(SRCARCH)/include/asm/module.lds.h, which is included from
scripts/module.lds.S.

scripts/module.lds is fine because 'make clean' keeps all the
build artifacts under scripts/.

You can add arch-specific sections in <asm/module.lds.h>.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Palmer Dabbelt <palmerdabbelt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Jessica Yu <jeyu@kernel.org>


# 017dab34 23-Sep-2020 Jiri Olsa <jolsa@kernel.org>

bpf: Check CONFIG_BPF option for resolve_btfids

Currently all the resolve_btfids 'users' are under CONFIG_BPF
code, so if we have CONFIG_BPF disabled, resolve_btfids will
fail, because there's no data to resolve.

Disabling resolve_btfids if there's CONFIG_BPF disabled,
so we won't fail such builds.

Suggested-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200923185735.3048198-1-jolsa@kernel.org


# ba4f184e 20-Sep-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc6


# 856deb86 13-Sep-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc5


# f4d51dff 06-Sep-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc4


# 318af7b8 17-Jul-2020 Josh Poimboeuf <jpoimboe@redhat.com>

Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"

Use of the new -flive-patching flag was introduced with the following
commit:

43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")

This flag has several drawbacks:

- It disables some optimizations, so it can have a negative effect on
performance.

- According to the GCC documentation it's not compatible with LTO, which
will become a compatibility issue as LTO support gets upstreamed in
the kernel.

- It was intended to be used for source-based patch generation tooling,
as opposed to binary-based patch generation tooling (e.g.,
kpatch-build). It probably should have at least been behind a
separate config option so as not to negatively affect other livepatch
users.

- Clang doesn't have the flag, so as far as I can tell, this method of
generating patches is incompatible with Clang, which like LTO is
becoming more mainstream.

- It breaks GCC's implicit noreturn detection for local functions. This
is the cause of several "unreachable instruction" objtool warnings.

- The broken noreturn detection is an obvious GCC regression, but we
haven't yet gotten GCC developers to acknowledge that, which doesn't
inspire confidence in their willingness to keep the feature working as
optimizations are added or changed going forward.

- While there *is* a distro which relies on this flag for their distro
livepatch module builds, there's not a publicly documented way to
create safe livepatch modules with it. Its use seems to be based on
tribal knowledge. It serves no benefit to those who don't know how to
use it.

(In fact, I believe the current livepatch documentation and samples
are misleading and dangerous, and should be corrected. Or at least
amended with a disclaimer. But I don't feel qualified to make such
changes.)

Also, we have an idea for using objtool to detect function changes,
which could potentially obsolete the need for this flag anyway.

At this point the flag has no benefits for upstream which would
counteract the above drawbacks. Revert it until it becomes more ready.

This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9.

Fixes: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com


# f75aef39 30-Aug-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc3


# 6ad7cbc0 22-Aug-2020 Nathan Huckleberry <nhuck@google.com>

Makefile: Add clang-tidy and static analyzer support to makefile

This patch adds clang-tidy and the clang static-analyzer as make
targets. The goal of this patch is to make static analysis tools
usable and extendable by any developer or researcher who is familiar
with basic c++.

The current static analysis tools require intimate knowledge of the
internal workings of the static analysis. Clang-tidy and the clang
static analyzers expose an easy to use api and allow users unfamiliar
with clang to write new checks with relative ease.

===Clang-tidy===

Clang-tidy is an easily extendable 'linter' that runs on the AST.
Clang-tidy checks are easy to write and understand. A check consists of
two parts, a matcher and a checker. The matcher is created using a
domain specific language that acts on the AST
(https://clang.llvm.org/docs/LibASTMatchersReference.html). When AST
nodes are found by the matcher a callback is made to the checker. The
checker can then execute additional checks and issue warnings.

Here is an example clang-tidy check to report functions that have calls
to local_irq_disable without calls to local_irq_enable and vice-versa.
Functions flagged with __attribute((annotation("ignore_irq_balancing")))
are ignored for analysis. (https://reviews.llvm.org/D65828)

===Clang static analyzer===

The clang static analyzer is a more powerful static analysis tool that
uses symbolic execution to find bugs. Currently there is a check that
looks for potential security bugs from invalid uses of kmalloc and
kfree. There are several more general purpose checks that are useful for
the kernel.

The clang static analyzer is well documented and designed to be
extensible.
(https://clang-analyzer.llvm.org/checker_dev_manual.html)
(https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf)

The main draw of the clang tools is how accessible they are. The clang
documentation is very nice and these tools are built specifically to be
easily extendable by any developer. They provide an accessible method of
bug-finding and research to people who are not overly familiar with the
kernel codebase.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3d32285f 22-Aug-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: wire up the build rule of compile_commands.json to Makefile

Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.

If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.

This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.

Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.

You can create compile_commands.json from Make:

$ make -j$(nproc) CC=clang compile_commands.json

You can also build vmlinux, modules, and compile_commands.json all
together in a single command:

$ make -j$(nproc) CC=clang all compile_commands.json

It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.

This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:

- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs

I think it is fine for most developers because our main interest is
the kernel-space code.

If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:

$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py

Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.

Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.

However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.

So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>


# 23cd88c9 20-Aug-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: hide commands to run Kconfig, and show short log for syncconfig

Some targets (localyesconfig, localmodconfig, defconfig) hide the
command running, but the others do not.

Users know which Kconfig flavor they are running, so it is OK to hide
the command. Add $(Q) to all commands consistently. If you want to see
the full command running, pass V=1 from the command line.

syncconfig is the exceptional case, which occurs without explicit
command invocation by the user. Display the Kbuild-style log for it.
The ugly bare log will go away.

[Before]

scripts/kconfig/conf --syncconfig Kconfig

[After]

SYNC include/config/auto.conf

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 695afd3d 16-Aug-2020 Sedat Dilek <sedat.dilek@gmail.com>

kbuild: Simplify DEBUG_INFO Kconfig handling

While playing with [1] I saw that the handling
of CONFIG_DEBUG_INFO can be simplified.

[1] https://patchwork.kernel.org/patch/11716107/

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# d012a719 23-Aug-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc2


# efbf9726 12-Aug-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove redundant patterns in filter/filter-out

The '%' in filter/filter-out matches to any number of any characters,
including empty string.

So, '%config' matches to 'config', and '%install' to 'install'.

Drop the redundant patterns.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 9123e3a7 16-Aug-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.9-rc1


# 09c60546 11-Aug-2020 Feng Tang <feng.tang@intel.com>

./Makefile: add debug option to enable function aligned on 32 bytes

Recently 0day reported many strange performance changes (regression or
improvement), in which there was no obvious relation between the culprit
commit and the benchmark at the first look, and it causes people to doubt
the test itself is wrong.

Upon further check, many of these cases are caused by the change to the
alignment of kernel text or data, as whole text/data of kernel are linked
together, change in one domain may affect alignments of other domains.

gcc has an option '-falign-functions=n' to force text aligned, and with
that option enabled, some of those performance changes will be gone, like
[1][2][3].

Add this option so that developers and 0day can easily find performance
bump caused by text alignment change, as tracking these strange bump is
quite time consuming. Though it can't help in other cases like data
alignment changes like [4].

Following is some size data for v5.7 kernel built with a RHEL config used
in 0day:

text data bss dec filename
19738771 13292906 5554236 38585913 vmlinux.noalign
19758591 13297002 5529660 38585253 vmlinux.align32

Raw vmlinux size in bytes:

v5.7 v5.7+align32
253950832 254018000 +0.02%

Some benchmark data, most of them have no big change:

* hackbench: [ -1.8%, +0.5%]

* fsmark: [ -3.2%, +3.4%] # ext4/xfs/btrfs

* kbuild: [ -2.0%, +0.9%]

* will-it-scale: [ -0.5%, +1.8%] # mmap1/pagefault3

* netperf:
- TCP_CRR [+16.6%, +97.4%]
- TCP_RR [-18.5%, -1.8%]
- TCP_STREAM [ -1.1%, +1.9%]

[1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
[2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
[3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7f45@intel.com/
[4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/

Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: http://lkml.kernel.org/r/1595475001-90945-1-git-send-email-feng.tang@intel.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 132305b3 01-Aug-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: stop filtering out $(GCC_PLUGINS_CFLAGS) from cc-option base

Commit d26e94149276 ("kbuild: no gcc-plugins during cc-option tests")
was neeeded because scripts/Makefile.gcc-plugins was too early.

This is unneeded by including scripts/Makefile.gcc-plugins last,
and being careful to not add cc-option tests after it.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# e0fe0bbe 01-Aug-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: include scripts/Makefile.* only when relevant CONFIG is enabled

Currently, the top Makefile includes all of scripts/Makefile.<feature>
even if the associated CONFIG option is disabled.

Do not include unneeded Makefiles in order to slightly optimize the
parse stage.

Include $(include-y), and ignore $(include-).

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3ec8a5b3 01-Jul-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: do not export LDFLAGS_vmlinux

When you clean the build tree for ARCH=arm, you may see the following
error message from 'nm' command:

$ make -j24 ARCH=arm clean
CLEAN arch/arm/crypto
CLEAN arch/arm/kernel
CLEAN arch/arm/mach-at91
CLEAN arch/arm/mach-omap2
CLEAN arch/arm/vdso
CLEAN certs
CLEAN lib
CLEAN usr
CLEAN net/wireless
CLEAN drivers/firmware/efi/libstub
nm: 'arch/arm/boot/compressed/../../../../vmlinux': No such file
/bin/sh: 1: arithmetic expression: expecting primary: " "
CLEAN arch/arm/boot/compressed
CLEAN drivers/scsi
CLEAN drivers/tty/vt
CLEAN arch/arm/boot
CLEAN vmlinux.symvers modules.builtin modules.builtin.modinfo

Even if you rerun the same command, the error message will not be
shown despite vmlinux is already gone.

To reproduce it, the parallel option -j is needed. Single thread
cleaning always executes 'archclean', 'vmlinuxclean' in this order,
so vmlinux still exists when arch/arm/boot/compressed/ is cleaned.

Looking at arch/arm/boot/compressed/Makefile does not help understand
the reason of the error message. Both KBSS_SZ and LDFLAGS_vmlinux are
assigned with '=' operator, hence, they are not expanded unless used.
Obviously, 'make clean' does not use them.

In fact, the root cause exists in the top Makefile:

export LDFLAGS_vmlinux

Since LDFLAGS_vmlinux is an exported variable, LDFLAGS_vmlinux in
arch/arm/boot/compressed/Makefile is expanded when scripts/Makefile.clean
has a command to execute. This is why the error message shows up only
when there exist build artifacts in arch/arm/boot/compressed/.

Adding 'unexport LDFLAGS_vmlinux' to arch/arm/boot/compressed/Makefile
will fix it as far as ARCH=arm is concerned, but I think the proper fix
is to get rid of 'export LDFLAGS_vmlinux' from the top Makefile.

LDFLAGS_vmlinux in the top Makefile contains linker flags for the top
vmlinux. LDFLAGS_vmlinux in arch/arm/boot/compressed/Makefile is for
arch/arm/boot/compressed/vmlinux. They just happen to have the same
variable name, but are used for different purposes. Stop shadowing
LDFLAGS_vmlinux.

This commit passes LDFLAGS_vmlinux to scripts/link-vmlinux.sh via a
command line parameter instead of via an environment variable. LD and
KBUILD_LDFLAGS are exported, but I did the same for consistency. Anyway,
they must be included in cmd_link-vmlinux to allow if_changed to detect
the changes in LD or KBUILD_LDFLAGS.

The following Makefiles are not affected:

arch/arm/boot/compressed/Makefile
arch/h8300/boot/compressed/Makefile
arch/nios2/boot/compressed/Makefile
arch/parisc/boot/compressed/Makefile
arch/s390/boot/compressed/Makefile
arch/sh/boot/compressed/Makefile
arch/sh/boot/romimage/Makefile
arch/x86/boot/compressed/Makefile

They use ':=' or '=' to clear the LDFLAGS_vmlinux inherited from the
top Makefile.

We need to take a closer look at the impact to unicore32 and xtensa.

arch/unicore32/boot/compressed/Makefile only uses '+=' operator for
LDFLAGS_vmlinux. So, the decompressor previously inherited the linker
flags from the top Makefile.

However, commit 70fac51feaf2 ("unicore32 additional architecture files:
boot process") was merged before commit 1f2bfbd00e46 ("kbuild: link of
vmlinux moved to a script"). So, I rather consider this is a bug fix of
1f2bfbd00e46.

arch/xtensa/boot/boot-elf/Makefile is also affected, but this is also
considered a fix for the same reason. It did not inherit LDFLAGS_vmlinux
when commit 4bedea945451 ("[PATCH] xtensa: Architecture support for
Tensilica Xtensa Part 2") was merged. I deleted $(LDFLAGS_vmlinux),
which is now empty.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# bcf87687 02-Aug-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8


# 48f7ddf7 30-Jul-2020 Nick Terrell <terrelln@fb.com>

init: Add support for zstd compressed kernel

- Add the zstd and zstd22 cmds to scripts/Makefile.lib

- Add the HAVE_KERNEL_ZSTD and KERNEL_ZSTD options

Architecture specific support is still needed for decompression.

Signed-off-by: Nick Terrell <terrelln@fb.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20200730190841.2071656-4-nickrterrell@gmail.com


# 92ed3019 26-Jul-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc7


# ca9b31f6 21-Jul-2020 Fangrui Song <maskray@google.com>

Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation

When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if
$(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit,
GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to
/usr/bin/ and Clang as of 11 will search for both
$(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle.

GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle,
$(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice,
$(prefix)aarch64-linux-gnu/$needle rarely contains executables.

To better model how GCC's -B/--prefix takes in effect in practice, newer
Clang (since
https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90)
only searches for $(prefix)$needle. Currently it will find /usr/bin/as
instead of /usr/bin/aarch64-linux-gnu-as.

Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
(/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the
appropriate cross compiling GNU as (when -no-integrated-as is in
effect).

Cc: stable@vger.kernel.org
Reported-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://github.com/ClangBuiltLinux/linux/issues/1099
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# ba47d845 19-Jul-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc6


# c9a0f3b8 11-Jul-2020 Jiri Olsa <jolsa@kernel.org>

bpf: Resolve BTF IDs in vmlinux image

Using BTF_ID_LIST macro to define lists for several helpers
using BTF arguments.

And running resolve_btfids on vmlinux elf object during linking,
so the .BTF_ids section gets the IDs resolved.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200711215329.41165-5-jolsa@kernel.org


# 33a57ce0 11-Jul-2020 Jiri Olsa <jolsa@kernel.org>

bpf: Compile resolve_btfids tool at kernel compilation start

The resolve_btfids tool will be used during the vmlinux linking,
so it's necessary it's ready for it.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/20200711215329.41165-3-jolsa@kernel.org


# 11ba4688 12-Jul-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc5


# 20b1be59 07-Jul-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: fix single target builds for external modules

Commit f566e1fbadb6 ("kbuild: make multiple directory targets work")
broke single target builds for external modules. Fix this.

Fixes: f566e1fbadb6 ("kbuild: make multiple directory targets work")
Reported-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Bjørn Mork <bjorn@mork.no>


# 893ab004 26-Jun-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove cc-option test of -fno-stack-protector

Some Makefiles already pass -fno-stack-protector unconditionally.
For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.

No problem report so far about hard-coding this option. So, we can
assume all supported compilers know -fno-stack-protector.

GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)

Get rid of cc-option from -fno-stack-protector.

Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.

Note:
arch/mips/vdso/Makefile adds -fno-stack-protector twice, first
unconditionally, and second conditionally. I removed the second one.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# dcb7fd82 05-Jul-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc4


# 7f58b487 30-Jun-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make Clang build userprogs for target architecture

Programs added 'userprogs' should be compiled for the target
architecture i.e. the same architecture as the kernel.

GCC does this correctly since the target architecture is implied
by the toolchain prefix.

Clang builds userspace programs always for the host architecture
because the target triple is currently missing.

Fix this.

Fixes: 7f3a59db274c ("kbuild: add infrastructure to build userspace programs")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>


# 9ebcfadb 28-Jun-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc3


# 48778464 21-Jun-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc2


# 2c6d9636 19-Jun-2020 Masahiro Yamada <masahiroy@kernel.org>

Revert "Makefile: install modules.builtin even if CONFIG_MODULES=n"

This reverts commit e0b250b57dcf403529081e5898a9de717f96b76b,
which broke build systems that need to install files to a certain
path, but do not set INSTALL_MOD_PATH when invoking 'make install'.

$ make INSTALL_PATH=/tmp/destdir install
mkdir: cannot create directory ‘/lib/modules/5.8.0-rc1+/’: Permission denied
Makefile:1342: recipe for target '_builtin_inst_' failed
make: *** [_builtin_inst_] Error 1

While modules.builtin is useful also for CONFIG_MODULES=n, this change
in the behavior is quite unexpected. Maybe "make modules_install"
can install modules.builtin irrespective of CONFIG_MODULES as Jonas
originally suggested.

Anyway, that commit should be reverted ASAP.

Reported-by: Douglas Anderson <dianders@chromium.org>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>


# f0fe00d4 16-Jun-2020 glider@google.com <glider@google.com>

security: allow using Clang's zero initialization for stack variables

In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero. The future of this flag
is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497).
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases. Another
possible resolution is that -ftrivial-auto-var-init=zero will persist
(as certain users have already started depending on it), but the name
of the guard flag will change.

In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike pattern
initialization, which has a higher chance of triggering existing bugs,
zero initialization provides safe defaults for strings, pointers, indexes,
and sizes. On the other hand, pattern initialization remains safer for
return values. Chrome OS and Android are moving to using zero
initialization for production builds.

Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.

This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN
and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that
enables zero initialization for locals if the corresponding flags are
supported by Clang.

Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>


# 7b169944 11-Jun-2020 Arvind Sankar <nivedita@alum.mit.edu>

Makefile: Improve compressed debug info support detection

Commit
10e68b02c861 ("Makefile: support compressed debug info")
added support for compressed debug sections.

Support is detected by checking
- does the compiler support -gz=zlib
- does the assembler support --compressed-debug-sections=zlib
- does the linker support --compressed-debug-sections=zlib

However, the gcc driver's support for this option is somewhat
convoluted. The driver's builtin specs are set based on the version of
binutils that it was configured with. It reports an error if the
configure-time linker/assembler (i.e., not necessarily the actual
assembler that will be run) do not support the option, but only if the
assembler (or linker) is actually invoked when -gz=zlib is passed.

The cc-option check in scripts/Kconfig.include does not invoke the
assembler, so the gcc driver reports success even if it does not support
the option being passed to the assembler.

Because the as-option check passes the option directly to the assembler
via -Wa,--compressed-debug-sections=zlib, the gcc driver does not see
this option and will never report an error.

Combined with an installed version of binutils that is more recent than
the one the compiler was built with, it is possible for all three tests
to succeed, yet an actual compilation with -gz=zlib to fail.

Moreover, it is unnecessary to explicitly pass
--compressed-debug-sections=zlib to the assembler via -Wa, since the
driver will do that automatically when it supports -gz=zlib.

Convert the as-option to just -gz=zlib, simplifying it as well as
performing a better test of the gcc driver's capabilities.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b3a9e3b9 14-Jun-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.8-rc1


# e4a42c82 07-Jun-2020 Denis Efremov <efremov@linux.com>

kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov <efremov@linux.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 8dfb61dc 05-Jun-2020 Denis Efremov <efremov@linux.com>

kbuild: add variables for compression tools

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2

Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.

The credit goes to @grsecurity.

As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"

Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# e0b250b5 03-Jun-2020 Jonas Zeiger <jonas.zeiger@talpidae.net>

Makefile: install modules.builtin even if CONFIG_MODULES=n

Many applications check for available kernel features via:

- /proc/modules (loaded modules, present if CONFIG_MODULES=y)
- $(MODLIB)/modules.builtin (builtin modules)

They fail to detect features if the kernel was built with CONFIG_MODULES=n
and modules.builtin isn't installed.

Therefore, add the target "_builtin_inst_" and make "install" and
"modules_install" depend on it.

Tests results:

- make install: kernel image is copied as before, modules.builtin copied
- make modules_install: (CONFIG_MODULES=n) nothing is copied, exit 1

Signed-off-by: Jonas Zeiger <jonas.zeiger@talpidae.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 48a0f727 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

modpost: show warning if any of symbol dump files is missing

If modpost fails to load a symbol dump file, it cannot check unresolved
symbols, hence module dependency will not be added. Nor CRCs can be added.

Currently, external module builds check only $(objtree)/Module.symvers,
but it should check files specified by KBUILD_EXTRA_SYMBOLS as well.

Move the warning message from the top Makefile to scripts/Makefile.modpost
and print the warning if any dump file is missing.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 269a535c 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

modpost: generate vmlinux.symvers and reuse it for the second modpost

The full build runs modpost twice, first for vmlinux.o and second for
modules.

The first pass dumps all the vmlinux symbols into Module.symvers, but
the second pass parses vmlinux again instead of reusing the dump file,
presumably because it needs to avoid accumulating stale symbols.

Loading symbol info from a dump file is faster than parsing an ELF object.
Besides, modpost deals with various issues to parse vmlinux in the second
pass.

A solution is to make the first pass dumps symbols into a separate file,
vmlinux.symvers. The second pass reads it, and parses module .o files.
The merged symbol information is dumped into Module.symvers in the same
way as before.

This makes further modpost cleanups possible.

Also, it fixes the problem of 'make vmlinux', which previously overwrote
Module.symvers, throwing away module symbols.

I slightly touched scripts/link-vmlinux.sh so that vmlinux is re-linked
when you cross this commit. Otherwise, vmlinux.symvers would not be
generated.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b2c88554 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: update modules.order only when contained modules are updated

Make modules.order depend on $(obj-m), and use if_changed to build it.
This will avoid unneeded update of modules.order, which will be useful
to optimize the modpost stage.

Currently, the second pass of modpost is always invoked. By checking the
timestamp of modules.order, we can avoid the unneeded modpost.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# f0d50ca0 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: refactor KBUILD_VMLINUX_{OBJS,LIBS} calculation

Do not overwrite core-y or drivers-y. Remove libs-y1 and libs-y2.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 95fb6317 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: merge net-y and virt-y into drivers-y

This will slightly change the link order; drivers-y from arch Makefile
will be linked after virt/built-in.a, but I guess this is not a big
deal.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 23febe37 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: merge init-y into core-y

No arch Makefile specifies init-y.

Merge init-y into core-y. This does not change the link order.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# fb2d99be 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: merge two 'ifdef CONFIG_TRIM_UNUSED_KSYMS' blocks

This hunk has two 'ifdef CONFIG_TRIM_UNUSED_KSYMS ... endif' blocks
with no other code interleaved. Merge them.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 4b50c8c4 31-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: force to build vmlinux if CONFIG_MODVERSION=y

This code does not work as stated in the comment.

$(CONFIG_MODVERSIONS) is always empty because it is expanded before
include/config/auto.conf is included. Hence, 'make modules' with
CONFIG_MODVERSION=y cannot record the version CRCs.

This has been broken since 2003, commit ("kbuild: Enable modules to be
build using the "make dir/" syntax"). [1]

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=15c6240cdc44bbeef3c4797ec860f9765ef4f1a7
Cc: linux-stable <stable@vger.kernel.org> # v2.5.71+
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3d77e6a8 31-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7


# 10e68b02 26-May-2020 Nick Desaulniers <ndesaulniers@google.com>

Makefile: support compressed debug info

As debug information gets larger and larger, it helps significantly save
the size of vmlinux images to compress the information in the debug
information sections. Note: this debug info is typically split off from
the final compressed kernel image, which is why vmlinux is what's used
in conjunction with GDB. Minimizing the debug info size should have no
impact on boot times, or final compressed kernel image size.

All of the debug sections will have a `C` flag set.
$ readelf -S <object file>

$ bloaty vmlinux.gcc75.compressed.dwarf4 -- \
vmlinux.gcc75.uncompressed.dwarf4

FILE SIZE VM SIZE
-------------- --------------
+0.0% +18 [ = ] 0 [Unmapped]
-73.3% -114Ki [ = ] 0 .debug_aranges
-76.2% -2.01Mi [ = ] 0 .debug_frame
-73.6% -2.89Mi [ = ] 0 .debug_str
-80.7% -4.66Mi [ = ] 0 .debug_abbrev
-82.9% -4.88Mi [ = ] 0 .debug_ranges
-70.5% -9.04Mi [ = ] 0 .debug_line
-79.3% -10.9Mi [ = ] 0 .debug_loc
-39.5% -88.6Mi [ = ] 0 .debug_info
-18.2% -123Mi [ = ] 0 TOTAL

$ bloaty vmlinux.clang11.compressed.dwarf4 -- \
vmlinux.clang11.uncompressed.dwarf4

FILE SIZE VM SIZE
-------------- --------------
+0.0% +23 [ = ] 0 [Unmapped]
-65.6% -871 [ = ] 0 .debug_aranges
-77.4% -1.84Mi [ = ] 0 .debug_frame
-82.9% -2.33Mi [ = ] 0 .debug_abbrev
-73.1% -2.43Mi [ = ] 0 .debug_str
-84.8% -3.07Mi [ = ] 0 .debug_ranges
-65.9% -8.62Mi [ = ] 0 .debug_line
-86.2% -40.0Mi [ = ] 0 .debug_loc
-42.0% -64.1Mi [ = ] 0 .debug_info
-22.1% -122Mi [ = ] 0 TOTAL

For x86_64 defconfig + LLVM=1 (before):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:22.03
Maximum resident set size (kbytes): 43856

For x86_64 defconfig + LLVM=1 (after):
Elapsed (wall clock) time (h:mm:ss or m:ss): 3:32.52
Maximum resident set size (kbytes): 1566776

Thanks to:
Nick Clifton helped us to provide the minimal binutils version.
Sedat Dilek found an increase in size of debug .deb package.

Cc: Nick Clifton <nickc@redhat.com>
Suggested-by: David Blaikie <blaikie@google.com>
Reviewed-by: Fangrui Song <maskray@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# e9e81b63 24-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: disallow multi-word in M= or KBUILD_EXTMOD

$(firstword ...) in scripts/Makefile.modpost was added by commit
3f3fd3c05585 ("[PATCH] kbuild: allow multi-word $M in Makefile.modpost")
to build multiple external module directories.

It was a solution to resolve symbol dependencies when an external
module depends on another external module.

Commit 0d96fb20b7ed ("kbuild: Add new Kbuild variable
KBUILD_EXTRA_SYMBOLS") introduced another solution by passing symbol
info via KBUILD_EXTRA_SYMBOLS, then broke the multi-word M= support.

include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \
$(KBUILD_EXTMOD)/Kbuild, $(KBUILD_EXTMOD)/Makefile)

... does not work if KBUILD_EXTMOD contains multiple words.

This feature has been broken for more than a decade. Remove the
bitrotten code, and stop parsing if M or KBUILD_EXTMOD contains
multiple words.

As Documentation/kbuild/modules.rst explains, if your module depends
on another one, there are two solutions:
- add a common top-level Kbuild file
- use KBUILD_EXTRA_SYMBOLS

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b480fec9 21-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: clear KBUILD_MODULES in top Makefile if CONFIG_MODULES=n

Do not try to build any module-related artifacts when CONFIG_MODULES
is disabled.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 8451791d 10-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make module name conflict fatal error

I think all the warnings have been fixed by now. Make it a fatal error.

Check it before modpost because we need to stop building *.ko files.
Also, pass modules.order via a script parameter.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 121c2a13 10-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: error out if targets prefixed with '__' are directly run

Some targets are internal-use only.

It is tedious to care about "what if __build_one_by_one is contained
in $(MAKECMDGOALS)?" etc.

Prefix internal targets with double underscores. Stop parsing Makefile
if they are directly run.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 93fdddfe 10-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add this-makefile as a shorthand for $(lastword $(MAKEFILE_LIST))

Make it clearer, and self-documenting.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 0663c68c 04-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS

Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES
because the difference is just the -r option passed to the 'rm' command.

Do likewise as commit 1634f2bfdb84 ("kbuild: remove clean-dirs syntax").

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 610134b7 04-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove misleading stale FIXME comment

This comment was added by commit ("kbuild: Restore build nr, improve
vmlinux link") [1].

It was talking about if_changed_rule at that time. Now, it is unclear
what to fix.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=ea52ca1b3e3882b499cc6c043f384958b88b62ff
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 3044dd05 01-May-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: invoke syncconfig if autoconf.h is missing

If include/generated/autoconf.h is accidentally lost somehow,
there is no clear way to fix it. Make it self-healing.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 9cb1fd0e 24-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc7


# b9bbe6ed 17-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc6


# 7f3a59db 28-Apr-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add infrastructure to build userspace programs

Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).

Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.

Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.

The implementation just mimics scripts/Makefile.host

The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).

This new syntax has two usecases.

- Sample programs

Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.

However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.

- Bpfilter

net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.

[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>


# d08b9f0c 27-Apr-2020 Sami Tolvanen <samitolvanen@google.com>

scs: Add support for Clang's Shadow Call Stack (SCS)

This change adds generic support for Clang's Shadow Call Stack,
which uses a shadow stack to protect return addresses from being
overwritten by an attacker. Details are available here:

https://clang.llvm.org/docs/ShadowCallStack.html

Note that security guarantees in the kernel differ from the ones
documented for user space. The kernel must store addresses of
shadow stacks in memory, which means an attacker capable reading
and writing arbitrary memory may be able to locate them and hijack
control flow by modifying the stacks.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
[will: Numerous cosmetic changes]
Signed-off-by: Will Deacon <will@kernel.org>


# ea21e904 25-Apr-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove '/' target

This notice has been here for a while. Remove it entirely now.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 2ef96a5b 10-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc5


# adc71920 09-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

gcc-10: disable 'restrict' warning for now

gcc-10 now warns about passing aliasing pointers to functions that take
restricted pointers.

That's actually a great warning, and if we ever start using 'restrict'
in the kernel, it might be quite useful. But right now we don't, and it
turns out that the only thing this warns about is an idiom where we have
declared a few functions to be "printf-like" (which seems to make gcc
pick up the restricted pointer thing), and then we print to the same
buffer that we also use as an input.

And people do that as an odd concatenation pattern, with code like this:

#define sysfs_show_gen_prop(buffer, fmt, ...) \
snprintf(buffer, PAGE_SIZE, "%s"fmt, buffer, __VA_ARGS__)

where we have 'buffer' as both the destination of the final result, and
as the initial argument.

Yes, it's a bit questionable. And outside of the kernel, people do have
standard declarations like

int snprintf( char *restrict buffer, size_t bufsz,
const char *restrict format, ... );

where that output buffer is marked as a restrict pointer that cannot
alias with any other arguments.

But in the context of the kernel, that 'use snprintf() to concatenate to
the end result' does work, and the pattern shows up in multiple places.
And we have not marked our own version of snprintf() as taking restrict
pointers, so the warning is incorrect for now, and gcc picks it up on
its own.

If we do start using 'restrict' in the kernel (and it might be a good
idea if people find places where it matters), we'll need to figure out
how to avoid this issue for snprintf and friends. But in the meantime,
this warning is not useful.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 5a76021c 09-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

gcc-10: disable 'stringop-overflow' warning for now

This is the final array bounds warning removal for gcc-10 for now.

Again, the warning is good, and we should re-enable all these warnings
when we have converted all the legacy array declaration cases to
flexible arrays. But in the meantime, it's just noise.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 44720996 09-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

gcc-10: disable 'array-bounds' warning for now

This is another fine warning, related to the 'zero-length-bounds' one,
but hitting the same historical code in the kernel.

Because C didn't historically support flexible array members, we have
code that instead uses a one-sized array, the same way we have cases of
zero-sized arrays.

The one-sized arrays come from either not wanting to use the gcc
zero-sized array extension, or from a slight convenience-feature, where
particularly for strings, the size of the structure now includes the
allocation for the final NUL character.

So with a "char name[1];" at the end of a structure, you can do things
like

v = my_malloc(sizeof(struct vendor) + strlen(name));

and avoid the "+1" for the terminator.

Yes, the modern way to do that is with a flexible array, and using
'offsetof()' instead of 'sizeof()', and adding the "+1" by hand. That
also technically gets the size "more correct" in that it avoids any
alignment (and thus padding) issues, but this is another long-term
cleanup thing that will not happen for 5.7.

So disable the warning for now, even though it's potentially quite
useful. Having a slew of warnings that then hide more urgent new issues
is not an improvement.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 5c45de21 09-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

gcc-10: disable 'zero-length-bounds' warning for now

This is a fine warning, but we still have a number of zero-length arrays
in the kernel that come from the traditional gcc extension. Yes, they
are getting converted to flexible arrays, but in the meantime the gcc-10
warning about zero-length bounds is very verbose, and is hiding other
issues.

I missed one actual build failure because it was hidden among hundreds
of lines of warning. Thankfully I caught it on the second go before
pushing things out, but it convinced me that I really need to disable
the new warnings for now.

We'll hopefully be all done with our conversion to flexible arrays in
the not too distant future, and we can then re-enable this warning.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 78a5255f 09-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Stop the ad-hoc games with -Wno-maybe-initialized

We have some rather random rules about when we accept the
"maybe-initialized" warnings, and when we don't.

For example, we consider it unreliable for gcc versions < 4.9, but also
if -O3 is enabled, or if optimizing for size. And then various kernel
config options disabled it, because they know that they trigger that
warning by confusing gcc sufficiently (ie PROFILE_ALL_BRANCHES).

And now gcc-10 seems to be introducing a lot of those warnings too, so
it falls under the same heading as 4.9 did.

At the same time, we have a very straightforward way to _enable_ that
warning when wanted: use "W=2" to enable more warnings.

So stop playing these ad-hoc games, and just disable that warning by
default, with the known and straight-forward "if you want to work on the
extra compiler warnings, use W=123".

Would it be great to have code that is always so obvious that it never
confuses the compiler whether a variable is used initialized or not?
Yes, it would. In a perfect world, the compilers would be smarter, and
our source code would be simpler.

That's currently not the world we live in, though.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 0e698dfa 03-May-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc4


# 6a8b55ed 26-Apr-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc3


# ae83d0b4 19-Apr-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc2


# 8f3d9f35 12-Apr-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.7-rc1


# a0d1c951 07-Apr-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

As Documentation/kbuild/llvm.rst implies, building the kernel with a
full set of LLVM tools gets very verbose and unwieldy.

Provide a single switch LLVM=1 to use Clang and LLVM tools instead
of GCC and Binutils. You can pass it from the command line or as an
environment variable.

Please note LLVM=1 does not turn on the integrated assembler. You need
to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the
integrated assembler, I think we can make it default.

We discussed what we need, and we agreed to go with a simple boolean
flag that switches both target and host tools:

https://lkml.org/lkml/2020/3/28/494
https://lkml.org/lkml/2020/4/3/43

Some items discussed, but not adopted:

- LLVM_DIR

When multiple versions of LLVM are installed, I just thought supporting
LLVM_DIR=/path/to/my/llvm/bin/ might be useful.

CC = $(LLVM_DIR)clang
LD = $(LLVM_DIR)ld.lld
...

However, we can handle this by modifying PATH. So, we decided to not do
this.

- LLVM_SUFFIX

Some distributions (e.g. Debian) package specific versions of LLVM with
naming conventions that use the version as a suffix.

CC = clang$(LLVM_SUFFIX)
LD = ld.lld(LLVM_SUFFIX)
...

will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
but the suffixed versions in /usr/bin/ are symlinks to binaries in
/usr/lib/llvm-#/bin/, so this can also be handled by PATH.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 7e20e47c 07-Apr-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: replace AS=clang with LLVM_IAS=1

The 'AS' variable is unused for building the kernel. Only the remaining
usage is to turn on the integrated assembler. A boolean flag is a better
fit for this purpose.

AS=clang was added for experts. So, I replaced it with LLVM_IAS=1,
breaking the backward compatibility.

Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 7273ad2b 11-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y

Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.

The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux, whereas the objects from lib-y are linked
as needed; if there is no user of a lib-y object, it is not linked.

lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.

Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).

Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.

At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.

Examples:

- drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
into vmlinux in the own way (arm64), or linked to the decompressor
(arm, x86).

- arch/alpha/lib/Makefile builds lib.a which is linked not only to
vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.

- arch/xtensa/boot/lib/Makefile builds lib.a for use from
arch/xtensa/boot/boot-redboot/Makefile.

One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).

For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.

The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.

x86_64_defconfig:

text data bss dec hex filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.after

The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.

ARCH=x86 allnoconfig + CONFIG_MODULES=y:

text data bss dec hex filename
1175162 254740 1220608 2650510 28718e vmlinux.before
1177974 254836 1220608 2653418 287cea vmlinux.after

Hopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.

If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.

Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# afe956c5 26-Mar-2020 Nathan Chancellor <nathan@kernel.org>

kbuild: Enable -Wtautological-compare

Currently, we disable -Wtautological-compare, which in turn disables a
bunch of more specific tautological comparison warnings that are useful
for the kernel such as -Wtautological-bitwise-compare. See clang's
documentation below for the other warnings that are suppressed by
-Wtautological-compare. Now that all of the major/noisy warnings have
been fixed, enable -Wtautological-compare so that more issues can be
caught at build time by various continuous integration setups.

-Wtautological-constant-out-of-range-compare is kept disabled under a
normal build but visible at W=1 because there are places in the kernel
where a constant or variable size can change based on the kernel
configuration. These are not fixed in a clean/concise way and the ones
I have audited so far appear to be harmless. It is not a subgroup but
rather just one warning so we do not lose out on much coverage by
default.

Link: https://github.com/ClangBuiltLinux/linux/issues/488
Link: http://releases.llvm.org/10.0.0/tools/clang/docs/DiagnosticsReference.html#wtautological-compare
Link: https://bugs.llvm.org/show_bug.cgi?id=42666
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# e51d8dac 30-Mar-2020 Shuah Khan <skhan@linuxfoundation.org>

Makefile: Update kselftest help information

Update kselftest help information.

Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 7111951b 29-Mar-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6


# 4623980d 26-Mar-2020 David Engraf <david.engraf@sysgo.com>

kbuild: add outputmakefile to no-dot-config-targets

The target outputmakefile is used to generate a Makefile
for out-of-tree builds and does not depend on the kernel
configuration.

Signed-off-by: David Engraf <david.engraf@sysgo.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# aa824e0c 25-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove AS variable

As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from
documents") noted, we rarely use $(AS) directly in the kernel build.

Now that the only/last user of $(AS) in drivers/net/wan/Makefile was
converted to $(CC), $(AS) is no longer used in the build process.

You can still pass in AS=clang, which is just a switch to turn on
the LLVM integrated assembler.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>


# f463c351 24-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add comment about grouped target

GNU Make commit 8c888d95f618 ("[SV 8297] Implement "grouped targets"
for explicit rules.") added the '&:' syntax.

I think '&:' is a perfect fit here, but we cannot use it any time
soon. Just add a TODO comment.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 735aab1e 24-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add -Wall to KBUILD_HOSTCXXFLAGS

Add -Wall to catch more warnings for C++ host programs.

When I submitted the previous version, the 0-day bot reported
-Wc++11-compat warnings for old GCC:

HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:28:0,
from scripts/gcc-plugins/gcc-common.h:15,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:102:21: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
^
/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/config/elfos.h:170:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/tm.h:42:0,
from scripts/gcc-plugins/gcc-common.h:15,
from scripts/gcc-plugins/latent_entropy_plugin.c:78:
/usr/lib/gcc/x86_64-linux-gnu/4.8/plugin/include/defaults.h:126:24: warning: C++11 requires a space between string literal and macro [-Wc++11-compat]
fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \
^

The source of the warnings is in the plugin headers, so we have no
control of it. I just suppressed them by adding -Wno-c++11-compat to
scripts/gcc-plugins/Makefile.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Kees Cook <keescook@chromium.org>


# 2431f22a 06-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: compute the dtbs_install destination more simply

The 'dtbinst_root' is used to remember the root of the in-kernel dts
directory (i.e. arch/*/boot/dts), but it looks clumsy.

I prefer using two variables 'obj' and 'dst' to track the in-kernel
directory and the install destination, respectively.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 16fbf79b 22-Mar-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc7


# b1112139 16-Mar-2020 Sergei Trofimovich <slyfox@gentoo.org>

Makefile: disallow data races on gcc-10 as well

gcc-10 will rename --param=allow-store-data-races=0
to -fno-allow-store-data-races.

The flag change happened at https://gcc.gnu.org/PR92046.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# fb33c651 15-Mar-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc6


# 9dffecc1 03-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: allow to run dt_binding_check without kernel configuration

The dt_binding_check target is located outside of the
'ifneq ($(dtstree),) ... endif' block.

So, you can run 'make dt_binding_check' on any architecture.
This makes a perfect sense because the dt-schema is arch-agnostic.

The only one problem I see is that scripts/dtc/dtc is not always built.
For example, ARCH=x86 defconfig does not define CONFIG_DTC. Kbuild
descends into scripts/dtc/ with doing nothing. Then, it fails to build
*.example.dt.yaml files.

Let's build scripts/dtc/dtc forcibly when running dt_binding_check.

The dt-schema does not depend on any CONFIG option either, so you
should be able to run dt_binding_check without the .config file.

Going forward, you can directly run 'make dt_binding_check' in a
pristine source tree.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>


# e10c4321 03-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: allow to run dt_binding_check and dtbs_check in a single command

Since commit 93512dad334d ("dt-bindings: Improve validation build error
handling"), 'make dtbs_check' does not validate the schema fully.

If you want to check everything, you need to run two commands separately.

$ make ARCH=arm dt_binding_check
$ make ARCH=arm dtbs_check

They are exclusive each other, so you cannot do like this:

$ make ARCH=arm dt_binding_check dtbs_check

In this case, dt-doc-validate and dt-extract-example are skipped
because CHECK_DTBS is set.

Let's make it possible to run these two targets in a single command.
It will be useful for schema writers.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>


# b5154bf6 03-Mar-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check

'make dtbs_check' checks the shecma in addition to building *.dtb files,
in other words, 'make dtbs_check' is a super-set of 'make dtbs'.
So, you do not have to do 'make dtbs dtbs_check', but I want to keep
the build system as robust as possible in any use.

Currently, 'dtbs' and 'dtbs_check' are independent of each other.
In parallel building, two threads descend into arch/*/boot/dts/,
one for dtbs and the other for dtbs_check, then end up with building
the same DTB simultaneously.

This commit fixes the concurrency issue. Otherwise, I see build errors
like follows:

$ make ARCH=arm64 defconfig
$ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check
<snip>
DTC arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb
DTC arch/arm64/boot/dts/freescale/imx8mn-evk.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
DTC arch/arm64/boot/dts/zte/zx296718-pcbox.dtb
DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb
DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb
DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb
DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb
CHECK arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml
fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory
make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2
make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb'
make[2]: *** Waiting for unfinished jobs....
DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb
DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb
DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb
DTC arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb
fixdep: parse error; no targets found
make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1
make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb'
make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2
make[1]: *** Waiting for unfinished jobs....
DTC arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>


# 46b7c492 29-Feb-2020 SZ Lin (林上智) <sz.lin@moxa.com>

kbuild: Fix inconsistent comment

The commit 2042b5486bd3 ("kbuild: unset variables in top Makefile
instead of setting 0") renamed the variable from "config-targets"
to "config-build", the comment should be consistent accordingly.

Signed-off-by: Kaiden PK Yu (余泊鎧) <KaidenPK.Yu@moxa.com>
Signed-off-by: SZ Lin (林上智) <sz.lin@moxa.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 2c523b34 08-Mar-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc5


# 88694cff 28-Feb-2020 Quentin Perret <qperret@google.com>

kbuild: generate autoksyms.h early

When doing a cold build, autoksyms.h starts empty, and is updated late
in the build process to have visibility over the symbols used by in-tree
drivers. But since the symbol whitelist is known upfront, it can be used
to pre-populate autoksyms.h and maximize the amount of code that can be
compiled to its final state in a single pass, hence reducing build time.

Do this by using gen_autoksyms.sh to initialize autoksyms.h instead of
creating an empty file.

Acked-by: Nicolas Pitre <nico@fluxnic.net>
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# 2a86f661 27-Feb-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: use KBUILD_DEFCONFIG as the fallback for DEFCONFIG_LIST

Most of the Kconfig commands (except defconfig and all*config) read
the .config file as a base set of CONFIG options.

When it does not exist, the files in DEFCONFIG_LIST are searched in
this order and loaded if found.

I do not see much sense in the last two lines in DEFCONFIG_LIST.

[1] ARCH_DEFCONFIG

The entry for DEFCONFIG_LIST is guarded by 'depends on !UML'. So, the
ARCH_DEFCONFIG definition in arch/x86/um/Kconfig is meaningless.

arch/{sh,sparc,x86}/Kconfig define ARCH_DEFCONFIG depending on 32 or
64 bit variant symbols. This is a little bit strange; ARCH_DEFCONFIG
should be a fixed string because the base config file is loaded before
the symbol evaluation stage.

Using KBUILD_DEFCONFIG makes more sense because it is fixed before
Kconfig is invoked. Fortunately, arch/{sh,sparc,x86}/Makefile define it
in the same way, and it works as expected. Hence, replace ARCH_DEFCONFIG
with "arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)".

[2] arch/$(ARCH)/defconfig

This file path is no longer valid. The defconfig files are always located
in the arch configs/ directories.

$ find arch -name defconfig | sort
arch/alpha/configs/defconfig
arch/arm64/configs/defconfig
arch/csky/configs/defconfig
arch/nds32/configs/defconfig
arch/riscv/configs/defconfig
arch/s390/configs/defconfig
arch/unicore32/configs/defconfig

The path arch/*/configs/defconfig is already covered by
"arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG)". So, this file path is
not necessary.

I moved the default KBUILD_DEFCONFIG to the top Makefile. Otherwise,
the 7 architectures listed above would end up with endless loop of
syncconfig.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# a83e4ca2 16-Feb-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove cc-option switch from -Wframe-larger-than=

This CONFIG option was added by commit 35bb5b1e0e84 ("Add option to
enable -Wframe-larger-than= on gcc 4.4"). At that time, the cc-option
check was needed.

According to Documentation/process/changes.rst, the current minimal
supported version of GCC is 4.6, so you can assume GCC supports it.
Clang supports it as well.

Remove the cc-option switch and redundant comments.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 98d54f81 01-Mar-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc4


# c473a8d0 22-Feb-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add dt_binding_check to PHONY in a correct place

The dt_binding_check is added to PHONY, but it is invisible when
$(dtstree) is empty. So, it is not specified as phony for
ARCH=x86 etc.

Add it to PHONY outside the ifneq ... endif block.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>


# 964a596d 22-Feb-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: add dtbs_check to PHONY

The dtbs_check should be a phony target, but currently it is not
specified so.

'make dtbs_check' works even if a file named 'dtbs_check' exists
because it depends on another phony target, scripts_dtc, but we
should not rely on it.

Add dtbs_check to PHONY.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>


# 505b12b3 12-Feb-2020 Randy Dunlap <rdunlap@infradead.org>

kbuild: add comment for V=2 mode

Complete the comments for valid values of KBUILD_VERBOSE,
specifically for KBUILD_VERBOSE=2.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# f8788d86 23-Feb-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc3


# 11a48a5a 16-Feb-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc2


# bb6d3fb3 09-Feb-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.6-rc1


# f566e1fb 04-Feb-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: make multiple directory targets work

Currently, the single-target build does not work when two
or more sub-directories are given:

$ make fs/ kernel/ lib/
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtool
make[2]: Nothing to be done for 'kernel/'.
make[2]: Nothing to be done for 'fs/'.
make[2]: Nothing to be done for 'lib/'.

Make it work properly.

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# d5226fa6 26-Jan-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5


# def9d278 19-Jan-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc7


# 94f7345b 06-Jan-2020 Masahiro Yamada <masahiroy@kernel.org>

kbuild: remove PYTHON2 variable

Python 2 has retired. There is no user of this variable.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# b3a987b0 12-Jan-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc6


# 8b41fc44 19-Dec-2019 Masahiro Yamada <masahiroy@kernel.org>

kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf

Commit bc081dd6e9f6 ("kbuild: generate modules.builtin") added
infrastructure to generate modules.builtin, the list of all
builtin modules.

Basically, it works like this:

- Kconfig generates include/config/tristate.conf, the list of
tristate CONFIG options with a value in a capital letter.

- scripts/Makefile.modbuiltin makes Kbuild descend into
directories to collect the information of builtin modules.

I am not a big fan of it because Kbuild ends up with traversing
the source tree twice.

I am not sure how perfectly it should work, but this approach cannot
avoid false positives; even if the relevant CONFIG option is tristate,
some Makefiles forces obj-m to obj-y.

Some examples are:

arch/powerpc/platforms/powermac/Makefile:
obj-$(CONFIG_NVRAM:m=y) += nvram.o

net/ipv6/Makefile:
obj-$(subst m,y,$(CONFIG_IPV6)) += inet6_hashtables.o

net/netlabel/Makefile:
obj-$(subst m,y,$(CONFIG_IPV6)) += netlabel_calipso.o

Nobody has complained about (or noticed) it, so it is probably fine to
have false positives in modules.builtin.

This commit simplifies the implementation. Let's exploit the fact
that every module has MODULE_LICENSE(). (modpost shows a warning if
MODULE_LICENSE is missing. If so, 0-day bot would already have blocked
such a module.)

I added MODULE_FILE to <linux/module.h>. When the code is being compiled
as builtin, it will be filled with the file path of the module, and
collected into modules.builtin.info. Then, scripts/link-vmlinux.sh
extracts the list of builtin modules out of it.

This new approach fixes the false-positives above, but adds another
type of false-positives; non-modular code may have MODULE_LICENSE()
by mistake. This is not a big deal, it is just the code is always
orphan. We can clean it up if we like. You can see cleanup examples by:

$ git log --grep='make.* explicitly non-modular'

To sum up, this commits deletes lots of code, but still produces almost
equivalent results. Please note it does not increase the vmlinux size at
all. As you can see in include/asm-generic/vmlinux.lds.h, the .modinfo
section is discarded in the link stage.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# c79f46a2 05-Jan-2020 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc5


# fd698849 29-Dec-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc4


# 46cf053e 22-Dec-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc3


# d1eef1c6 15-Dec-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc2


# eefb8c12 04-Dec-2019 Dmitry Golovin <dima@golovin.in>

x86/boot: kbuild: allow readelf executable to be specified

Introduce a new READELF variable to top-level Makefile, so the name of
readelf binary can be specified.

Before this change the name of the binary was hardcoded to
"$(CROSS_COMPILE)readelf" which might not be present for every
toolchain.

This allows to build with LLVM Object Reader by using make parameter
READELF=llvm-readelf.

Link: https://github.com/ClangBuiltLinux/linux/issues/771
Signed-off-by: Dmitry Golovin <dima@golovin.in>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>


# e42617b8 08-Dec-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.5-rc1


# 219d5433 24-Nov-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4


# b1fbfcb4 17-Nov-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make single target builds even faster

Commit 2dffd23f81a3 ("kbuild: make single target builds much faster")
made the situation much better.

To improve it even more, apply the similar idea to the top Makefile.
Trim unrelated directories from build-dirs.

The single build code must be moved above the 'descend' target.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jens Axboe <axboe@kernel.dk>


# af42d346 17-Nov-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc8


# dfd402a4 14-Nov-2019 Marco Elver <elver@google.com>

kcsan: Add Kernel Concurrency Sanitizer infrastructure

Kernel Concurrency Sanitizer (KCSAN) is a dynamic data-race detector for
kernel space. KCSAN is a sampling watchpoint-based data-race detector.
See the included Documentation/dev-tools/kcsan.rst for more details.

This patch adds basic infrastructure, but does not yet enable KCSAN for
any architecture.

Signed-off-by: Marco Elver <elver@google.com>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>


# 7ecaf069 07-Nov-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move headers_check rule to usr/include/Makefile

Currently, some sanity checks for uapi headers are done by
scripts/headers_check.pl, which is wired up to the 'headers_check'
target in the top Makefile.

It is true compiling headers has better test coverage, but there
are still several headers excluded from the compile test. I like
to keep headers_check.pl for a while, but we can delete a lot of
code by moving the build rule to usr/include/Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# fcbb8461 07-Nov-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove header compile test

There are both positive and negative options about this feature.
At first, I thought it was a good idea, but actually Linus stated a
negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
is ugly and annoying.

The baseline I'd like to keep is the compile-test of uapi headers.
(Otherwise, kernel developers have no way to ensure the correctness
of the exported headers.)

I will maintain a small build rule in usr/include/Makefile.
Remove the other header test functionality.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 80591e61 09-Nov-2019 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: tell sparse about the $ARCH

Sparse uses the same executable for all archs and uses flags
like -m64, -mbig-endian or -D__arm__ for arch-specific parameters.
But Sparse also uses value from the host machine used to build
Sparse as default value for the target machine.

This works, of course, well for native build but can create
problems when cross-compiling, like defining both '__i386__'
and '__arm__' when cross-compiling for arm on a x86-64 machine.

Fix this by explicitely telling sparse the target architecture.

Reported-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# bc35d4bd 29-Oct-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

scripts/nsdeps: support nsdeps for external module builds

scripts/nsdeps is written to take care of only in-tree modules.
Perhaps, this is not a bug, but just a design. At least,
Documentation/core-api/symbol-namespaces.rst focuses on in-tree modules.

Having said that, some people already tried nsdeps for external modules.
So, it would be nice to support it.

Reported-by: Steve French <smfrench@gmail.com>
Reported-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
Reviewed-by: Matthias Maennich <maennich@google.com>
Tested-by: Matthias Maennich <maennich@google.com>


# bbc55bde 29-Oct-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

modpost: dump missing namespaces into a single modules.nsdeps file

The modpost, with the -d option given, generates per-module .ns_deps
files.

Kbuild generates per-module .mod files to carry module information.
This is convenient because Make handles multiple jobs in parallel
when the -j option is given.

On the other hand, the modpost always runs as a single thread.
I do not see a strong reason to produce separate .ns_deps files.

This commit changes the modpost to generate just one file,
modules.nsdeps, each line of which has the following format:

<module_name>: <list of missing namespaces>

Please note it contains *missing* namespaces instead of required ones.
So, modules.nsdeps is empty if the namespace dependency is all good.

This will work more efficiently because spatch will no longer process
already imported namespaces. I removed the '(if needed)' from the
nsdeps log since spatch is invoked only when needed.

This also solves the stale .ns_deps problem reported by Jessica Yu:

https://lkml.org/lkml/2019/10/28/467

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jessica Yu <jeyu@kernel.org>
Acked-by: Jessica Yu <jeyu@kernel.org>
Reviewed-by: Matthias Maennich <maennich@google.com>
Tested-by: Matthias Maennich <maennich@google.com>


# bff9c62b 29-Oct-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

modpost: do not invoke extra modpost for nsdeps

'make nsdeps' invokes the modpost three times at most; before linking
vmlinux, before building modules, and finally for generating .ns_deps
files. Running the modpost again and again is not efficient.

The last two can be unified. When the -d option is given, the modpost
still does the usual job, and in addition, generates .ns_deps files.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Matthias Maennich <maennich@google.com>
Reviewed-by: Matthias Maennich <maennich@google.com>


# 4234448b 25-Oct-2019 Geert Uytterhoeven <geert+renesas@glider.be>

kbuild: Extend defconfig field size from 24 to 27

There are 6 defconfigs with names longer than 24 characters, breaking
alignment in "make help".

The "winner" is "ecovec24-romimage_defconfig", counting in at 27
characters.

Extend the defconfig field size to 27 to restore alignment.
Don't use a larger value, to not encourage people to create even longer
defconfig names.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a64c0440 25-Oct-2019 Geert Uytterhoeven <geert+renesas@glider.be>

kbuild: Wrap long "make help" text lines

Some "make help" text lines extend beyond 80 characters.
Wrap them before an opening parenthesis, or before 80 characters.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 35e046a2 15-Oct-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unneeded variable, single-all

When single-build is set, everything in $(MAKECMDGOALS) is a single
target. You can use $(MAKECMDGOALS) to list out the single targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 31f4f5b4 10-Nov-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc7


# a99d8080 03-Nov-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc6


# d6d5df1d 27-Oct-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc5


# 7d194c21 20-Oct-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc4


# 85f0ae7e 21-Sep-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: update comment about KBUILD_ALLDIRS

Commit 000ec95fbe75 ("kbuild: pkg: rename scripts/package/Makefile to
scripts/Makefile.package") missed to update this comment.

Fixes: 000ec95fbe75 ("kbuild: pkg: rename scripts/package/Makefile to scripts/Makefile.package")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4f5cafb5 13-Oct-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc3


# d85103ac 03-Oct-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix build error of 'make nsdeps' in clean tree

Running 'make nsdeps' in a clean source tree fails as follows:

$ make -s clean; make -s defconfig; make nsdeps
[ snip ]
awk: fatal: cannot open file `init/modules.order' for reading (No such file or directory)
make: *** [Makefile;1307: modules.order] Error 2
make: *** Deleting file 'modules.order'
make: *** Waiting for unfinished jobs....

The cause of the error is 'make nsdeps' does not build modules at all.
Set KBUILD_MODULES to fix it.

Reviewed-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>


# da0c9ea1 06-Oct-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc2


# 17eac6c2 26-Sep-2019 Shuah Khan <skhan@linuxfoundation.org>

selftests: Add kselftest-all and kselftest-install targets

Add kselftest-all target to build tests from the top level
Makefile. This is to simplify kselftest use-cases for CI and
distributions where build and test systems are different.

Current kselftest target builds and runs tests on a development
system which is a developer use-case.

Add kselftest-install target to install tests from the top level
Makefile. This is to simplify kselftest use-cases for CI and
distributions where build and test systems are different.

This change addresses requests from developers and testers to add
support for installing kselftest from the main Makefile.

In addition, make the install directory the same when install is
run using "make kselftest-install" or by running kselftest_install.sh.
Also fix the INSTALL_PATH variable conflict between main Makefile and
selftests Makefile.

Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>


# 7e35b425 21-Sep-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove SUBDIRS support

Linux 5.3 is out. Remove the SUBDIRS support.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 13dc8c02 21-Sep-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove ar-option and KBUILD_ARFLAGS

Commit 40df759e2b9e ("kbuild: Fix build with binutils <= 2.19")
introduced ar-option and KBUILD_ARFLAGS to deal with old binutils.

According to Documentation/process/changes.rst, the current minimal
supported version of binutils is 2.21 so you can assume the 'D' option
is always supported. Not only GNU ar but also llvm-ar supports it.

With the 'D' option hard-coded, there is no more user of ar-option
or KBUILD_ARFLAGS.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# 54ecb8f7 30-Sep-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.4-rc1


# 4d856f72 15-Sep-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3


# eb8305ae 06-Sep-2019 Matthias Maennich <maennich@google.com>

scripts: Coccinelle script for namespace dependencies.

A script that uses the '<module>.ns_deps' files generated by modpost to
automatically add the required symbol namespace dependencies to each
module.

Usage:
1) Move some symbols to a namespace with EXPORT_SYMBOL_NS() or define
DEFAULT_SYMBOL_NAMESPACE
2) Run 'make' (or 'make modules') and get warnings about modules not
importing that namespace.
3) Run 'make nsdeps' to automatically add required import statements
to said modules.

This makes it easer for subsystem maintainers to introduce and maintain
symbol namespaces into their codebase.

Co-developed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Martijn Coenen <maco@android.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>


# 1d082773 06-Sep-2019 Matthias Maennich <maennich@google.com>

modpost: add support for generating namespace dependencies

This patch adds an option to modpost to generate a <module>.ns_deps file
per module, containing the namespace dependencies for that module.

E.g. if the linked module my-module.ko would depend on the symbol
myfunc.MY_NS in the namespace MY_NS, the my-module.ns_deps file created
by modpost would contain the entry MY_NS to express the namespace
dependency of my-module imposed by using the symbol myfunc.

These files can subsequently be used by static analysis tools (like
coccinelle scripts) to address issues with missing namespace imports. A
later patch of this series will introduce such a script 'nsdeps' and a
corresponding make target to automatically add missing
MODULE_IMPORT_NS() definitions to the module's sources. For that it uses
the information provided in the generated .ns_deps files.

Co-developed-by: Martijn Coenen <maco@android.com>
Signed-off-by: Martijn Coenen <maco@android.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Jessica Yu <jeyu@kernel.org>


# f74c2bb9 08-Sep-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc8


# e27128db 31-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN

KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
options for GCC, but now it is a historical misnomer since we use it
also for Clang, DTC, and even kernel-doc.

Rename it to more sensible, shorter KBUILD_EXTRA_WARN.

For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
supported (but not advertised in the documentation).

I also fixed up 'make help', and updated the documentation.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>


# 858805b3 25-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add $(BASH) to run scripts with bash-extension

CONFIG_SHELL falls back to sh when bash is not installed on the system,
but nobody is testing such a case since bash is usually installed.
So, shell scripts invoked by CONFIG_SHELL are only tested with bash.

It makes it difficult to test whether the hashbang #!/bin/sh is real.
For example, #!/bin/sh in arch/powerpc/kernel/prom_init_check.sh is
false. (I fixed it up)

Besides, some shell scripts invoked by CONFIG_SHELL use bash-extension
and #!/bin/bash is specified as the hashbang, while CONFIG_SHELL may
not always be set to bash.

Probably, the right thing to do is to introduce BASH, which is bash by
default, and always set CONFIG_SHELL to sh. Replace $(CONFIG_SHELL)
with $(BASH) for bash scripts.

If somebody tries to add bash-extension to a #!/bin/sh script, it will
be caught in testing because /bin/sh is a symlink to dash on some major
distributions.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8cc7af75 20-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove ARCH_{CPP,A,C}FLAGS

These flags were added by commit 61754c18752f ("kbuild: Allow arch
Makefiles to override {cpp,ld,c}flags") to allow ARC to override -O2.

We did not see any other usage after all. Now that ARC switched to
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3, there is no more user of
these variables.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 15f5db60 20-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild,arc: add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 for ARC

arch/arc/Makefile overrides -O2 with -O3. This is the only user of
ARCH_CFLAGS. There is no user of ARCH_CPPFLAGS or ARCH_AFLAGS.
My plan is to remove ARCH_{CPP,A,C}FLAGS after refactoring the ARC
Makefile.

Currently, ARC has no way to enable -Wmaybe-uninitialized because both
-O3 and -Os disable it. Enabling it will be useful for compile-testing.
This commit allows allmodconfig (, which defaults to -O2) to enable it.

Add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3=y to all the defconfig files
in arch/arc/configs/ in order to keep the current config settings.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>


# 089cf7f6 02-Sep-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc7


# e2079e93 26-Aug-2019 Nathan Chancellor <nathan@kernel.org>

kbuild: Do not enable -Wimplicit-fallthrough for clang for now

This functionally reverts commit bfd77145f35c ("Makefile: Convert
-Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang").

clang enabled support for -Wimplicit-fallthrough in C in r369414 [1],
which causes a lot of warnings when building the kernel for two reasons:

1. Clang does not support the /* fall through */ comments. There seems
to be a general consensus in the LLVM community that this is not
something they want to support. Joe Perches wrote a script to convert
all of the comments to a "fallthrough" keyword that will be added to
compiler_attributes.h [2] [3], which catches the vast majority of the
comments. There doesn't appear to be any consensus in the kernel
community when to do this conversion.

2. Clang and GCC disagree about falling through to final case statements
with no content or cases that simply break:

https://godbolt.org/z/c8csDu

This difference contributes at least 50 warnings in an allyesconfig
build for x86, not considering other architectures. This difference
will need to be discussed to see which compiler is right [4] [5].

[1]: https://github.com/llvm/llvm-project/commit/1e0affb6e564b7361b0aadb38805f26deff4ecfc
[2]: https://lore.kernel.org/lkml/61ddbb86d5e68a15e24ccb06d9b399bbf5ce2da7.camel@perches.com/
[3]: https://lore.kernel.org/lkml/1d2830aadbe9d8151728a7df5b88528fc72a0095.1564549413.git.joe@perches.com/
[4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432
[5]: https://github.com/ClangBuiltLinux/linux/issues/636

Given these two problems need discussion and coordination, do not enable
-Wimplicit-fallthrough with clang right now. Add a comment to explain
what is going on as well. This commit should be reverted once these two
issues are fully flushed out and resolved.

Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 36de077b 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: check clean srctree even earlier

Move the outputmakefile target to the leftmost in the prerequisite list
so that this is checked first. GNU Make processes the prerequisites
left to right.

GNU Make will keep to stick to this behavior, and it seems even
POSIX standard, according to this:
https://lists.gnu.org/archive/html/bug-make/2019-08/msg00030.html

The POSIX standard of make is available here:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

Of course, when the parallel option -j given, other targets will be run
simultaneously but it is nice to show the error as early as possible.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a5139fb3 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove prepare3 target

Now prepare3 does nothing but depends on include/config/kernel.release

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# e8e83a23 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move the clean srctree check to the outputmakefile target

With this commit, the error report is shown earlier, even before
running kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 1a475d54 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clarify where to run make mrproper when out-of-tree fails

If you try out-of-tree build with an unclean source tree, Kbuild
suggests to run make mrproper. The path to the source tree may be
shown with a relative path, for example, "make O=foo" emits the
following:

.. is not clean, please run 'make mrproper'
in the '..' directory.

This is somewhat confusing if you ran "make O=foo" in the source tree.
Using the absolute path will be clearer.

This commit changes the error message like follows:

***
*** The source tree is not clean, please run 'make mrproper'
*** in /absolute/path/to/linux
***

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 621da4ba 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: Inform user to pass ARCH= for make mrproper only when necessary

Since commit 3a475b2166fd ("kbuild: Inform user to pass ARCH= for make
mrproper"), if you try out-of-tree build with an unclean source tree,
it suggests to run 'make ARCH=<ARCH> mrproper'.

This looks odd when you are not cross-compiling the kernel. Show the
'ARCH=<ARCH>' part only when ARCH= was given from the command line.
If ARCH is the default (native build) or came from the environment,
it should simply suggest 'make mrproper' as before.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 59747fb8 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove 'Using ... as source for kernel' message

You already know the location of the source tree without this message.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# bc7b752a 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unneeded dependency for $(DOC_TARGETS)

Commit 415008af3219 ("docs-rst: convert lsm from DocBook to ReST")
stopped using if_changed_rule. There is no more users of if_changed*
for the doc targets. Hence, fixdep is unneeded. Remove the dependency
on scripts_basic.

All the doc targets are phony. The dependency on FORCE is not needed
either.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a55aa89a 25-Aug-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc6


# 3e4c6948 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unneeded '+' marker from kselftest-merge

This line contains $(MAKE), so Make knows that it will invoke sub-make
without help of the '+' marker.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 000ec95f 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: pkg: rename scripts/package/Makefile to scripts/Makefile.package

scripts/package/Makefile does not use $(obj) or $(src) at all.
It actually generates files and directories in the top of $(objtree).
I do not see much sense in descending into scripts/package/.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 46a63d4b 21-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: pkg: clean up package files/dirs from the top Makefile

I am not a big fan of the $(objtree)/ hack for clean-files/clean-dirs.

These are created in the top of $(objtree), so let's clean them up
from the top Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9b9a3f20 14-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: split final module linking out into Makefile.modfinal

I think splitting the modpost and linking modules into separate
Makefiles will be useful especially when more complex build steps
come in. The main motivation of this commit is to integrate the
proposed klp-convert feature cleanly.

I moved the logging 'Building modules, stage 2.' to Makefile.modpost
to avoid the code duplication although I do not know whether or not
this message is needed in the first place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 10df0638 14-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: rebuild modules when module linker scripts are updated

Currently, the timestamp of module linker scripts are not checked.
Add them to the dependency of modules so they are correctly rebuilt.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 394053f4 14-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make single targets work more correctly

Currently, the single target build directly descends into the directory
of the target. For example,

$ make foo/bar/baz.o

... directly descends into foo/bar/.

On the other hand, the normal build usually descends one directory at
a time, i.e. descends into foo/, and then foo/bar/.

This difference causes some problems.

[1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles

The options in subdir-{as,cc}flags-y take effect in the current
and its sub-directories. In other words, they are inherited
downward. In the example above, the single target will miss
subdir-{as,cc}flags-y if they are defined in foo/Makefile.

[2] could be built in a different directory

As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can
handle files that are spread over several sub-directories.

The build rule of foo/bar/baz.o may not necessarily be specified in
foo/bar/Makefile. It might be specifies in foo/Makefile as follows:

[foo/Makefile]
obj-y := bar/baz.o

This often happens when a module is so big that its source files
are divided into sub-directories.

In this case, there is no Makefile in the foo/bar/ directory, yet
the single target descends into foo/bar/, then fails due to the
missing Makefile. You can still do 'make foo/bar/' for partial
building, but cannot do 'make foo/bar/baz.s'. I believe the single
target '%.s' is a useful feature for inspecting the compiler output.

Some modules work around this issue by putting an empty Makefile
in every sub-directory.

This commit fixes those problems by making the single target build
descend in the same way as the normal build does.

Another change is the single target build will observe the CONFIG
options. Previously, it allowed users to build the foo.o even when
the corresponding CONFIG_FOO is disabled:

obj-$(CONFIG_FOO) += foo.o

In the new behavior, the single target build will just fail and show
"No rule to make target ..." (or "Nothing to be done for ..." if the
stale object already exists, but cannot be updated).

The disadvantage of this commit is the build speed. Now that the
single target build visits every directory and parses lots of
Makefiles, it is slower than before. (But, I hope it will not be
too slow.)

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 76cd306d 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: unify clean-dirs rule for in-kernel and external module

Factor out the duplicated code for in-kernel and external module
cleaning.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# c99f3918 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: unify vmlinux-dirs and module-dirs rules

The in-kernel build and external module build have similar code
for descending into sub-directories.

Factor out the code into the common place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2042b548 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: unset variables in top Makefile instead of setting 0

There is no need to set 0 to variables such as config-targets,
mixed-targets, etc.

Unset instead of setting 0 in order to use 'ifdef' to test them.

I also renamed:

config-targets -> config-build
mixed-targets -> mixed-build
dot-config -> need-config

to clarify what we are doing.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 125d059b 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not descend to ./Kbuild when cleaning

'make clean' descends into ./Kbuild, but does not clean anything
since everything is added to no-clean-files.

There is no need to descend to ./Kbuild in the first place.
We can drop the no-clean-files assignment.

With this, there is no more user of no-clean-files. I will keep it
for a while to see whether a new user will appear.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d1abaeb3 18-Aug-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc5


# d4945049 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove 'make /' support

'make /' is just an alias for 'make ./'; this builds all objects of an
external module, but skips the modpost stage.

I am not a big fan of 'make /' since it looks as if it were touching
the root directory of the system. I like 'make ./' better.

I do not know how many people are using it, but let's show a hint if
it is used. Also, move it close to the external module rules since
this only makes sense for external modules.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 16b59cd7 10-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move the Module.symvers check for external module build

$(objtree)/Module.symvers is not required for descending into
sub-directories. It is needed for the modpost stage.

Move the Module.symvers check to the right place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7aa8dd91 13-Aug-2019 Stephen Boyd <sboyd@kernel.org>

devicetree: Expose dtbs_check and dt_binding_check some more

It wasn't obvious that this was a command to run based on 'make help',
so add it to the top-level help for devicetree builds. Also, add an
example to the documentation to show that db_binding_check can be run
with DT_SCHEMA_FILES= to only check one schema file instead of all of
them.

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: <linux-kbuild@vger.kernel.org>
Cc: <devicetree@vger.kernel.org>
Cc: <linux-doc@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
[robh: fix-up due to .md to .rst conversion]
Signed-off-by: Rob Herring <robh@kernel.org>


# d45331b0 11-Aug-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc4


# bfd77145 05-Aug-2019 Joe Perches <joe@perches.com>

Makefile: Convert -Wimplicit-fallthrough=3 to just -Wimplicit-fallthrough for clang

A compilation -Wimplicit-fallthrough warning was enabled by commit
a035d552a93b ("Makefile: Globally enable fall-through warning")

Even though clang 10.0.0 does not currently support this warning without
a patch, clang currently does not support a value for this option.

Link: https://bugs.llvm.org/show_bug.cgi?id=39382

The gcc default for this warning is 3 so removing the =3 has no effect
for gcc and enables the warning for patched versions of clang.

Also remove the =3 from an existing use in a parisc Makefile:
arch/parisc/math-emu/Makefile

Signed-off-by: Joe Perches <joe@perches.com>
Reviewed-and-tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# c07d8d47 08-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: show hint if subdir-y/m is used to visit module Makefile

Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead
of $(MODVERDIR)/*.mod"), a module is no longer built in the following
pattern:

[Makefile]
subdir-y := some-module

[some-module/Makefile]
obj-m := some-module.o

You cannot write Makefile this way in upstream because modules.order is
not correctly generated. subdir-y is used to descend to a sub-directory
that builds tools, device trees, etc.

For external modules, the modules order does not matter. So, the
Makefile above was known to work.

I believe the Makefile should be re-written as follows:

[Makefile]
obj-m := some-module/

[some-module/Makefile]
obj-m := some-module.o

However, people will have no idea if their Makefile suddenly stops
working. In fact, I received questions from multiple people.

Show a warning for a while if obj-m is specified in a Makefile visited
by subdir-y or subdir-m.

I touched the %/ rule to avoid false-positive warnings for the single
target.

Cc: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Tom Stonecypher <thomas.edwardx.stonecypher@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>


# 47801c97 02-Aug-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: revive single target %.ko

I removed the single target %.ko in commit ff9b45c55b26 ("kbuild:
modpost: read modules.order instead of $(MODVERDIR)/*.mod") because
the modpost stage does not work reliably. For instance, the module
dependency, modversion, etc. do not work if we lack symbol information
from the other modules.

Yet, some people still want to build only one module in their interest,
and it may be still useful if it is used within those limitations.

Fixes: ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod")
Reported-by: Don Brace <don.brace@microsemi.com>
Reported-by: Arend Van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7bac9870 21-Jan-2019 Vasily Gorbik <gor@linux.ibm.com>

kbuild: add OBJSIZE variable for the size tool

Define and export OBJSIZE variable for "size" tool from binutils to be
used in architecture specific Makefiles (naming the variable just "SIZE"
would be too risky). In particular this tool is useful to perform checks
that early boot code is not using bss section (which might have not been
zeroed yet or intersects with initrd or other files boot loader might
have put right after the linux kernel).

Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>


# 5cf896fb 31-Jul-2019 Peter Collingbourne <pcc@google.com>

arm64: Add support for relocating the kernel with RELR relocations

RELR is a relocation packing format for relative relocations.
The format is described in a generic-abi proposal:
https://groups.google.com/d/topic/generic-abi/bX460iggiKg/discussion

The LLD linker can be instructed to pack relocations in the RELR
format by passing the flag --pack-dyn-relocs=relr.

This patch adds a new config option, CONFIG_RELR. Enabling this option
instructs the linker to pack vmlinux's relative relocations in the RELR
format, and causes the kernel to apply the relocations at startup along
with the RELA relocations. RELA relocations still need to be applied
because the linker will emit RELA relative relocations if they are
unrepresentable in the RELR format (i.e. address not a multiple of 2).

Enabling CONFIG_RELR reduces the size of a defconfig kernel image
with CONFIG_RANDOMIZE_BASE by 3.5MB/16% uncompressed, or 550KB/5%
compressed (lz4).

Signed-off-by: Peter Collingbourne <pcc@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Will Deacon <will@kernel.org>


# e21a712a 04-Aug-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc3


# 5241ab4c 29-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: initialize CLANG_FLAGS correctly in the top Makefile

CLANG_FLAGS is initialized by the following line:

CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))

..., which is run only when CROSS_COMPILE is set.

Some build targets (bindeb-pkg etc.) recurse to the top Makefile.

When you build the kernel with Clang but without CROSS_COMPILE,
the same compiler flags such as -no-integrated-as are accumulated
into CLANG_FLAGS.

If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg',
Kbuild will recompile everything needlessly due to the build command
change.

Fix this by correctly initializing CLANG_FLAGS.

Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags")
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>


# 609488bc 28-Jul-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.3-rc2


# a035d552 06-Jun-2019 Gustavo A. R. Silva <gustavo@embeddedor.com>

Makefile: Globally enable fall-through warning

Now that all the fall-through warnings have been addressed in the
kernel, enable the fall-through warning globally.

Also, update the deprecated.rst file to include implicit fall-through
as 'deprecated' so people can be pointed to a single location for
justification.

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Kees Cook <keescook@chromium.org>
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>


# 5f9e832c 21-Jul-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linus 5.3-rc1


# 29be86d7 17-Jul-2019 Seth Forshee <seth.forshee@canonical.com>

kbuild: add -fcf-protection=none when using retpoline flags

The gcc -fcf-protection=branch option is not compatible with
-mindirect-branch=thunk-extern. The latter is used when
CONFIG_RETPOLINE is selected, and this will fail to build with
a gcc which has -fcf-protection=branch enabled by default. Adding
-fcf-protection=none when building with retpoline enabled
prevents such build failures.

Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 30527cef 17-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove 'prepare1' target

Now that there is no rule for 'prepare1', it can go away.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b7dca6dd 17-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: create *.mod with full directory path and remove MODVERDIR

While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.

To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mod files. This avoids descending into
directories again. This mechanism was introduced in 2003 or so.

Later, commit 551559e13af1 ("kbuild: implement modules.order") added
modules.order. So, we can simply read it out to know all the modules
with directory paths. This is easier than parsing the first line of
*.mod files.

$(MODVERDIR) has a flat directory structure, that is, *.mod files
are named only with base names. This is based on the assumption that
the module name is unique across the tree. This assumption is really
fragile.

Stephen Rothwell reported a race condition caused by a module name
conflict:

https://lkml.org/lkml/2019/5/13/991

In parallel building, two different threads could write to the same
$(MODVERDIR)/*.mod simultaneously.

Non-unique module names are the source of all kind of troubles, hence
commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
introduced a new checker script.

However, it is still fragile in the build system point of view because
this race happens before scripts/modules-check.sh is invoked. If it
happens again, the modpost will emit unclear error messages.

To fix this issue completely, create *.mod with full directory path
so that two threads never attempt to write to the same file.

$(MODVERDIR) is no longer needed.

Since modules with directory paths are listed in modules.order, Kbuild
is still able to find *.mod files without additional descending.

I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash
for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y,
it occurs not only in the modpost stage, but also during directory
descending, where sumversion.c may parse stale *.mod files. It would emit
'No such file or directory' warning when an object consisting a module is
renamed, or when a single-obj module is turned into a multi-obj module or
vice versa.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>


# ff9b45c5 17-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod

Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be processed. This is simpler than parsing *.mod
files in $(MODVERDIR).

For external modules, $(KBUILD_EXTMOD)/modules.order should be read.

I removed the single target %.ko from the top Makefile. To make sure
modpost works correctly, vmlinux and the other modules must be built.
You cannot build a particular .ko file alone.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 1bd9a468 17-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}

Removing the 'kernel/' prefix will make our life easier because we can
simply do 'cat modules.order' to get all built modules with full paths.

Currently, we parse the first line of '*.mod' files in $(MODVERDIR).
Since we have duplicated functionality here, I plan to remove MODVERDIR
entirely.

In fact, modules.order is generated also for external modules in a
broken format. It adds the 'kernel/' prefix to the absolute path of
the module, like this:

kernel//path/to/your/external/module/foo.ko

This is fine for now since modules.order is not used for external
modules. However, I want to sanitize the format everywhere towards
the goal of removing MODVERDIR.

We cannot change the format of installed module.{order,builtin}.
So, 'make modules_install' will add the 'kernel/' prefix while copying
them to $(MODLIB)/.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7e131918 17-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not create empty modules.order in the prepare stage

Currently, $(objtree)/modules.order is touched in two places.

In the 'prepare0' rule, scripts/Makefile.build creates an empty
modules.order while processing 'obj=.'

In the 'modules' rule, the top-level Makefile overwrites it with
the correct list of modules.

While this might be a good side-effect that modules.order is made
empty every time (probably this is not intended functionality),
I personally do not like this behavior.

Create modules.order only when it is sensible to do so.

This avoids creating the following pointless files:

scripts/basic/modules.order
scripts/dtc/modules.order
scripts/gcc-plugins/modules.order
scripts/genksyms/modules.order
scripts/mod/modules.order
scripts/modules.order
scripts/selinux/genheaders/modules.order
scripts/selinux/mdp/modules.order
scripts/selinux/modules.order

Going forward, $(objtree)/modules.order lists the modules that
was built in the last successful build.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 46457133 15-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove tag files by distclean instead of mrproper

It takes somewhat long time to generate these tag files.
Keep such precious files until we run 'make distclean'.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 89ff7131f 12-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add --hash-style= and --build-id unconditionally

As commit 1e0221374e30 ("mips: vdso: drop unnecessary cc-ldoption")
explained, these flags are supported by the minimal required version
of binutils. They are supported by ld.lld too.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>


# 3a475b21 09-Jul-2019 Geert Uytterhoeven <geert@linux-m68k.org>

kbuild: Inform user to pass ARCH= for make mrproper

When cross-compiling an out-of-tree build with an unclean source tree
directory, the build fails with:

/path/to/kernel/source/tree is not clean, please run 'make mrproper'
in the '/path/to/kernel/source/tree' directory.

However, doing so does not fix the problem, as "make mrproper" now
requires passing the target architecture to the make command, else it
won't remove $(srctree)/arch/$(SRCARCH)/include/generated.
"git ls-files -o" doesn't give a clue, as it doesn't list (empty)
directories, only files.

Improve usability by including the ARCH= option in the error output.

Fixes: a788b2ed81ab ("kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 95fd3f87 05-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add a flag to force absolute path for srctree

In old days, Kbuild always used an absolute path for $(srctree).

Since commit 890676c65d69 ("kbuild: Use relative path when building in
the source tree"), $(srctree) is '.' when O= was not passed from the
command line.

Yet, using absolute paths is useful in some cases even without O=, for
instance, to create a cscope file with absolute path tags.

'O=.' was known to work as a workaround to force Kbuild to use absolute
paths even when you are building in the source tree.

Since commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any
directory"), Kbuild is too clever to be tricked. Even if you pass 'O=.'
Kbuild notices you are building in the source tree, then use '.' for
$(srctree).

So, 'make O=. cscope' is no help to create absolute path tags.

We cannot force one or the other according to commit e93bc1a0cab3
("Revert "kbuild: specify absolute paths for cscope""). Both of
relative path and absolute path have pros and cons.

This commit adds a new flag KBUILD_ABS_SRCTREE to allow users to
choose the absolute path for $(srctree).

'make KBUILD_ABS_SRCTREE=1 cscope' will work as a replacement of
'make O=. cscope'.

Reported-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 051f278e 05-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: replace KBUILD_SRCTREE with boolean building_out_of_srctree

Commit 25b146c5b8ce ("kbuild: allow Kbuild to start from any directory")
deprecated KBUILD_SRCTREE.

It is only used in tools/testing/selftest/ to distinguish out-of-tree
build. Replace it with a new boolean flag, building_out_of_srctree.

I also replaced the conditional ($(srctree),.) because the next commit
will allow an absolute path to be used for $(srctree) even when building
in the source tree.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 75dd4747 05-Jul-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove src and obj from the top Makefile

Replace $(src) and $(obj) with $(srctree) and $(objtree), respectively.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 43c78d88 30-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: compile-test kernel headers to ensure they are self-contained

The headers in include/ are globally used in the kernel source tree
to provide common APIs. They are included from external modules, too.

It will be useful to make as many headers self-contained as possible
so that we do not have to rely on a specific include order.

There are more than 4000 headers in include/. In my rough analysis,
70% of them are already self-contained. With efforts, most of them
can be self-contained.

For now, we must exclude more than 1000 headers just because they
cannot be compiled as standalone units. I added them to header-test-.
The blacklist was mostly generated by a script, so the reason of the
breakage should be checked later.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>


# c93a0368 30-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not create wrappers for header-test-y

header-test-y does not work with headers in sub-directories.

For example, you may want to write a Makefile, like this:

include/linux/Kbuild:

header-test-y += mtd/nand.h

This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
with the following content:

#include "mtd/nand.h"

To make this work, we need to add $(srctree)/include/linux to the
header search path. It would be tedious to add ccflags-y.

Instead, we could change the *.hdrtest.c rule to wrap:

#include "nand.h"

This works for in-tree build since #include "..." searches in the
relative path from the header with this directive. For O=... build,
we need to add $(srctree)/include/linux/mtd to the header search path,
which will be even more tedious.

After all, I thought it would be handier to compile headers directly
without creating wrappers.

I added a new build rule to compile %.h into %.h.s

The target is %.h.s instead of %.h.o because it is slightly faster.
Also, as for GCC, an empty assembly is smaller than an empty object.

I wrote the build rule:

$(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<

instead of:

$(CC) $(c_flags) -S -o $@ -x c $<

Both work fine with GCC, but the latter is bad for Clang.

This comes down to the difference in the -Wunused-function policy.
GCC does not warn about unused 'static inline' functions at all.
Clang does not warn about the ones in included headers, but does
about the ones in the source. So, we should handle headers as
headers, not as source files.

In fact, this has been hidden since commit abb2ea7dfd82 ("compiler,
clang: suppress warning for unused static inline functions"), but we
should not rely on that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>


# d6fc9fcb 30-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: compile-test exported headers to ensure they are self-contained

Multiple people have suggested compile-testing UAPI headers to ensure
they can be really included from user-space. "make headers_check" is
obviously not enough to catch bugs, and we often leak unresolved
references to user-space.

Use the new header-test-y syntax to implement it. Please note exported
headers are compile-tested with a completely different set of compiler
flags. The header search path is set to $(objtree)/usr/include since
exported headers should not include unexported ones.

We use -std=gnu89 for the kernel space since the kernel code highly
depends on GNU extensions. On the other hand, UAPI headers should be
written in more standardized C, so they are compiled with -std=c90.
This will emit errors if C++ style comments, the keyword 'inline', etc.
are used. Please use C style comments (/* ... */), '__inline__', etc.
in UAPI headers.

There is additional compiler requirement to enable this test because
many of UAPI headers include <stdlib.h>, <sys/ioctl.h>, <sys/time.h>,
etc. directly or indirectly. You cannot use kernel.org pre-built
toolchains [1] since they lack <stdlib.h>.

I reused CONFIG_CC_CAN_LINK to check the system header availability.
The intention is slightly different, but a compiler that can link
userspace programs provide system headers.

For now, a lot of headers need to be excluded because they cannot
be compiled standalone, but this is a good start point.

[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>


# 0ecfebd2 07-Jul-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2


# 4e8fc3f5 25-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add more hints about SUBDIRS replacement

Commit 0126be38d988 ("kbuild: announce removal of SUBDIRS if used")
added a hint about the 'SUBDIRS' replacement, but it was not clear
enough.

Multiple people sent me similar questions, patches. For instance,

https://lkml.org/lkml/2019/1/17/456

I did not mean to use M= for building a subdirectory in the kernel tree.

From commit 669efc76b317 ("net: hns3: fix compile error"), people
already (ab)use M=... to do that because it seems to work to some extent.

Documentation/kbuild/kbuild.txt says M= and KBUILD_EXTMOD are used for
building external modules.

In fact, Kbuild supports the single target '%/' for this purpose, but
this may not be noticed much.

Kindly add more hints.

Makefile:213: ================= WARNING ================
Makefile:214: 'SUBDIRS' will be removed after Linux 5.3
Makefile:215:
Makefile:216: If you are building an individual subdirectory
Makefile:217: in the kernel tree, you can do like this:
Makefile:218: $ make path/to/dir/you/want/to/build/
Makefile:219: (Do not forget the trailing slash)
Makefile:220:
Makefile:221: If you are building an external module,
Makefile:222: Please use 'M=' or 'KBUILD_EXTMOD' instead
Makefile:223: ==========================================

Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>


# 876a0600 27-Jun-2019 Nathan Chancellor <nathan@kernel.org>

kbuild: Add ability to test Clang's integrated assembler

There are some people interested in experimenting with Clang's
integrated assembler. To make it easy to do so without source
modification, allow the user to specify 'AS=clang' as part of the
make command to avoid adding '-no-integrated-as' to the {A,C}FLAGS.

Link: https://github.com/ClangBuiltLinux/linux/issues/577
Suggested-by: Dmitry Golovin <dima@golovin.in>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 68980b47 23-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: split modules.order build rule out of 'modules' target

modules.order is a real target. Split its build rule out like
modules.builtin

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 50ef0cdf 23-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix missed rebuild of modules.builtin

Unlike modules.order, modules.builtin is not rebuilt every time.
Once modules.builtin is created, it will not be updated until
auto.conf or tristate.conf is changed.

So, it does not notice a change in Makefile, for example, the rename
of modules.

Kbuild must always descend into directories for modules.builtin too.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6fbc7275 29-Jun-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc7


# 589834b3 11-Jun-2019 Nathan Chancellor <nathan@kernel.org>

kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS

In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
a GCC only option so clang rightfully complains:

warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]

https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option

However, by default, this is merely a warning so the build happily goes
on with a slew of these warnings in the process.

Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
support clang") worked around this behavior in cc-option by adding
-Werror so that unknown flags cause an error. However, this all happens
silently and when an unknown flag is added to the build unconditionally
like -Wno-psabi, cc-option will always fail because there is always an
unknown flag in the list of flags. This manifested as link time failures
in the arm64 libstub because -fno-stack-protector didn't get added to
KBUILD_CFLAGS.

To avoid these weird cryptic failures in the future, make clang behave
like gcc and immediately error when it encounters an unknown flag by
adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
unconditionally for clang because it is supported by at least 3.0.0,
according to godbolt [1] and 4.0.0, according to its documentation [2],
which is far earlier than we typically support.

[1]: https://godbolt.org/z/7F7rm3
[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option

Link: https://github.com/ClangBuiltLinux/linux/issues/511
Link: https://github.com/ClangBuiltLinux/linux/issues/517
Suggested-by: Peter Smith <peter.smith@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4b972a01 22-Jun-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc6


# 9e0babf2 16-Jun-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc5


# e846f0dc 04-Jun-2019 Jani Nikula <jani.nikula@intel.com>

kbuild: add support for ensuring headers are self-contained

Sometimes it's useful to be able to explicitly ensure certain headers
remain self-contained, i.e. that they are compilable as standalone
units, by including and/or forward declaring everything they depend on.

Add special target header-test-y where individual Makefiles can add
headers to be tested if CONFIG_HEADER_TEST is enabled. This will
generate a dummy C file per header that gets built as part of extra-y.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a5bae54c 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move hdr-inst shorthand to top Makefile

Now that hdr-inst is used only in the top Makefile, move it there
from scripts/Kbuild.include.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d5470d14 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: re-implement Makefile.headersinst without recursion

Since commit fcc8487d477a ("uapi: export all headers under uapi
directories"), the headers in uapi directories are all exported by
default although exceptional cases are still allowed by the syntax
'no-export-headers'.

The traditional directory descending has been kept (in a somewhat
hacky way), but it is actually unneeded.

Get rid of it to simplify the code.

Also, handle files one by one instead of the previous per-directory
processing. This will emit much more log, but I like it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 59b2bd05 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add 'headers' target to build up uapi headers in usr/include

In Linux build system, build targets and installation targets are
separated.

Examples are:

- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include

[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# bdd7714b 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: build all prerequisites of headers_install simultaneously

Currently, scripts/unifdef is compiled after scripts_basic,
uapi-asm-generic, archheaders, and archscripts.

The proper dependency is just scripts_basic. There is no problem
to compile scripts/unifdef and other headers at the same time.

Split scripts_unifdef out in order to allow more parallel building.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2b8481be 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove build_unifdef target in scripts/Makefile

Since commit 2aedcd098a94 ("kbuild: suppress annoying "... is up to date."
message"), if_changed and friends nicely suppress "is up to date" messages.

We do not need per-Makefile tricks.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# e949f4c2 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add CONFIG_HEADERS_INSTALL and loosen the dependency of samples

Commit 5318321d367c ("samples: disable CONFIG_SAMPLES for UML") used
a big hammer to fix the build errors under the samples/ directory.
Only some samples actually include uapi headers from usr/include.

Introduce CONFIG_HEADERS_INSTALL since 'depends on HEADERS_INSTALL' is
clearer than 'depends on !UML'. If this option is enabled, uapi headers
are installed before starting directory descending.

I added 'depends on HEADERS_INSTALL' to per-sample CONFIG options.
This allows UML to compile some samples.

$ make ARCH=um allmodconfig samples/
[ snip ]
CC [M] samples/configfs/configfs_sample.o
CC [M] samples/kfifo/bytestream-example.o
CC [M] samples/kfifo/dma-example.o
CC [M] samples/kfifo/inttype-example.o
CC [M] samples/kfifo/record-example.o
CC [M] samples/kobject/kobject-example.o
CC [M] samples/kobject/kset-example.o
CC [M] samples/trace_events/trace-events-sample.o
CC [M] samples/trace_printk/trace-printk.o
AR samples/vfio-mdev/built-in.a
AR samples/built-in.a

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7a739ce5 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make gdb_script depend on prepare0 instead of prepare

'gdb_script' needs headers generated by ./Kbuild, which is visited
by 'prepare0'. None of 'gdb_script' depends on 'prepare'.

Loosen the dependency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 3a51f908 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove stale dependency between Documentation/ and headers_install

Commit 8e2faea877eb ("Make Documenation depend on headers_install")
dates back to 2014, which is before Sphinx was introduced for the
kernel documentation.

Since none of DOC_TARGET requires headers_install, it is strange to
run it only for the single target "Documentation/".

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f3c8d4c7 04-Jun-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove headers_{install,check}_all

headers_install_all does not make much sense any more because different
architectures export different set of uapi/linux/ headers. As you see
in include/uapi/linux/Kbuild, the installation of a.out.h, kvm.h, and
kvm_para.h is arch-dependent. So, headers_install_all repeats the
installation/removal of them.

If somebody really thinks it is useful to do headers_install for all
architectures, it would be possible by small shell-scripting, but
the top Makefile does not have to provide entry targets just for that
purpose.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>


# d1fdb6d8 08-Jun-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc4


# 6d3db46c 20-May-2019 Dan Rue <dan.rue@linaro.org>

kbuild: teach kselftest-merge to find nested config files

Current implementation of kselftest-merge only finds config files that
are one level deep using `$(srctree)/tools/testing/selftests/*/config`.

Often, config files are added in nested directories, and do not get
picked up by kselftest-merge.

Use `find` to catch all config files under
`$(srctree)/tools/testing/selftests` instead.

Signed-off-by: Dan Rue <dan.rue@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f2c7c76c 02-Jun-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc3


# cd6c84d8 26-May-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc2


# a188339c 19-May-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.2-rc1


# 3a48a919 17-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: check uniqueness of module names

In the recent build test of linux-next, Stephen saw a build error
caused by a broken .tmp_versions/*.mod file:

https://lkml.org/lkml/2019/5/13/991

drivers/net/phy/asix.ko and drivers/net/usb/asix.ko have the same
basename, and there is a race in generating .tmp_versions/asix.mod

Kbuild has not checked this before, and it suddenly shows up with
obscure error messages when this kind of race occurs.

Non-unique module names cause various sort of problems, but it is
not trivial to catch them by eyes.

Hence, this script.

It checks not only real modules, but also built-in modules (i.e.
controlled by tristate CONFIG option, but currently compiled with =y).
Non-unique names for built-in modules also cause problems because
/sys/modules/ would fall over.

For the latest kernel, I tested "make allmodconfig all" (or more
quickly "make allyesconfig modules"), and it detected the following:

warning: same basename if the following are built as modules:
drivers/regulator/88pm800.ko
drivers/mfd/88pm800.ko
warning: same basename if the following are built as modules:
drivers/gpu/drm/bridge/adv7511/adv7511.ko
drivers/media/i2c/adv7511.ko
warning: same basename if the following are built as modules:
drivers/net/phy/asix.ko
drivers/net/usb/asix.ko
warning: same basename if the following are built as modules:
fs/coda/coda.ko
drivers/media/platform/coda/coda.ko
warning: same basename if the following are built as modules:
drivers/net/phy/realtek.ko
drivers/net/dsa/realtek.ko

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>


# 233c741d 15-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add LICENSES to KBUILD_ALLDIRS

For *-pkg targets, the LICENSES directory should be included in the
source tarball.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 902a6898 09-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: terminate Kconfig when $(CC) or $(LD) is missing

If the compiler specified by $(CC) is not present, the Kconfig stage
sprinkles 'not found' messages, then succeeds.

$ make CROSS_COMPILE=foo defconfig
/bin/sh: 1: foogcc: not found
/bin/sh: 1: foogcc: not found
*** Default configuration is based on 'x86_64_defconfig'
./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
./scripts/gcc-version.sh: 17: ./scripts/gcc-version.sh: foogcc: not found
./scripts/gcc-version.sh: 18: ./scripts/gcc-version.sh: foogcc: not found
./scripts/gcc-version.sh: 19: ./scripts/gcc-version.sh: foogcc: not found
./scripts/clang-version.sh: 11: ./scripts/clang-version.sh: foogcc: not found
./scripts/gcc-plugin.sh: 11: ./scripts/gcc-plugin.sh: foogcc: not found
init/Kconfig:16:warning: 'GCC_VERSION': number is invalid
#
# configuration written to .config
#

Terminate parsing files immediately if $(CC) or $(LD) is not found.
"make *config" will fail more nicely.

$ make CROSS_COMPILE=foo defconfig
*** Default configuration is based on 'x86_64_defconfig'
scripts/Kconfig.include:34: compiler 'foogcc' not found
make[1]: *** [scripts/kconfig/Makefile;82: defconfig] Error 1
make: *** [Makefile;557: defconfig] Error 2

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d2f8ae0e 11-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: turn auto.conf.cmd into a mandatory include file

syncconfig is responsible for keeping auto.conf up-to-date, so if it
fails for any reason, the build must be terminated immediately.

However, since commit 9390dff66a52 ("kbuild: invoke syncconfig if
include/config/auto.conf.cmd is missing"), Kbuild continues running
even after syncconfig fails.

You can confirm this by intentionally making syncconfig error out:

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 08ba146..307b9de 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -1023,6 +1023,9 @@ int conf_write_autoconf(int overwrite)
FILE *out, *tristate, *out_h;
int i;

+ if (overwrite)
+ return 1;
+
if (!overwrite && is_present(autoconf_name))
return 0;

Then, syncconfig fails, but Make would not stop:

$ make -s mrproper allyesconfig defconfig
$ make
scripts/kconfig/conf --syncconfig Kconfig

*** Error during sync of the configuration.

make[2]: *** [scripts/kconfig/Makefile;69: syncconfig] Error 1
make[1]: *** [Makefile;557: syncconfig] Error 2
make: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf'
make: Failed to remake makefile 'include/config/auto.conf'.
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
[ continue running ... ]

The reason is in the behavior of a pattern rule with multi-targets.

%/auto.conf %/auto.conf.cmd %/tristate.conf: $(KCONFIG_CONFIG)
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig

GNU Make knows this rule is responsible for making all the three files
simultaneously. As far as examined, auto.conf.cmd is the target in
question when this rule is invoked. It is probably because auto.conf.cmd
is included below the inclusion of auto.conf.

The inclusion of auto.conf is mandatory, while that of auto.conf.cmd
is optional. GNU Make does not care about the failure in the process
of updating optional include files.

I filed this issue (https://savannah.gnu.org/bugs/?56301) in case this
behavior could be improved somehow in future releases of GNU Make.
Anyway, it is quite easy to fix our Makefile.

Given that auto.conf is already a mandatory include file, there is no
reason to stick auto.conf.cmd optional. Make it mandatory as well.

Cc: linux-stable <stable@vger.kernel.org> # 5.0+
Fixes: 9390dff66a52 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a1494304 10-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add all Clang-specific flags unconditionally

We do not support old Clang versions. Upgrade your clang version
if any of these flags is unsupported.

Let's add all flags inside ifdef CONFIG_CC_IS_CLANG unconditionally.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# 7eb8e5f0 09-May-2019 Nathan Chancellor <nathan@kernel.org>

kbuild: Don't try to add '-fcatch-undefined-behavior' flag

This is no longer a valid option in clang, it was removed in 3.5, which
we don't support.

https://github.com/llvm/llvm-project/commit/cb3f812b6b9fab8f3b41414f24e90222170417b4

Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8289f913 09-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Wvla flag unconditionally

This flag is documented in the GCC 4.6 manual, and recognized by
Clang as well. Let's rip off the cc-option switch.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Kees Cook <keescook@chromium.org>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# a3bc8864 08-May-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: re-enable int-in-bool-context warning

This warning was disabled by commit bd664f6b3e37 ("disable new
gcc-7.1.1 warnings for now") just because it was too noisy.

Thanks to Arnd Bergmann, all warnings have been fixed. Now, we are
ready to re-enable it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>


# 898490c0 29-Apr-2019 Alexey Gladkov <gladkov.alexey@gmail.com>

moduleparam: Save information about built-in modules in separate file

Problem:

When a kernel module is compiled as a separate module, some important
information about the kernel module is available via .modinfo section of
the module. In contrast, when the kernel module is compiled into the
kernel, that information is not available.

Information about built-in modules is necessary in the following cases:

1. When it is necessary to find out what additional parameters can be
passed to the kernel at boot time.

2. When you need to know which module names and their aliases are in
the kernel. This is very useful for creating an initrd image.

Proposal:

The proposed patch does not remove .modinfo section with module
information from the vmlinux at the build time and saves it into a
separate file after kernel linking. So, the kernel does not increase in
size and no additional information remains in it. Information is stored
in the same format as in the separate modules (null-terminated string
array). Because the .modinfo section is already exported with a separate
modules, we are not creating a new API.

It can be easily read in the userspace:

$ tr '\0' '\n' < modules.builtin.modinfo
ext4.softdep=pre: crc32c
ext4.license=GPL
ext4.description=Fourth Extended Filesystem
ext4.author=Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
ext4.alias=fs-ext4
ext4.alias=ext3
ext4.alias=fs-ext3
ext4.alias=ext2
ext4.alias=fs-ext2
md_mod.alias=block-major-9-*
md_mod.alias=md
md_mod.description=MD RAID framework
md_mod.license=GPL
md_mod.parmtype=create_on_open:bool
md_mod.parmtype=start_dirty_degraded:int
...

Co-Developed-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: Alexey Gladkov <gladkov.alexey@gmail.com>
Acked-by: Jessica Yu <jeyu@kernel.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# e93c9c99 05-May-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1


# 1eaca4b9 26-Apr-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move Documentation to vmlinux-alldirs

A minor code cleanup.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d93a18f2 26-Apr-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move samples/ to KBUILD_VMLINUX_OBJS

Handle samples/ like the other top-level directories to simplify
the Makefile.

Include include/config/auto.conf earlier to evaluate
drivers-$(CONFIG_SAMPLES).

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6f303d60 01-May-2019 Linus Torvalds <torvalds@linux-foundation.org>

gcc-9: silence 'address-of-packed-member' warning

We already did this for clang, but now gcc has that warning too. Yes,
yes, the address may be unaligned. And that's kind of the point.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 37624b58 28-Apr-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc7


# 709a972e 10-Apr-2019 Kees Cook <keescook@chromium.org>

security: Implement Clang's stack initialization

CONFIG_INIT_STACK_ALL turns on stack initialization based on
-ftrivial-auto-var-init in Clang builds, which has greater coverage
than CONFIG_GCC_PLUGINS_STRUCTLEAK_BYREF_ALL.

-ftrivial-auto-var-init Clang option provides trivial initializers for
uninitialized local variables, variable fields and padding.

It has three possible values:
pattern - uninitialized locals are filled with a fixed pattern
(mostly 0xAA on 64-bit platforms, see https://reviews.llvm.org/D54604
for more details, but 0x000000AA for 32-bit pointers) likely to cause
crashes when uninitialized value is used;
zero (it's still debated whether this flag makes it to the official
Clang release) - uninitialized locals are filled with zeroes;
uninitialized (default) - uninitialized locals are left intact.

This patch uses only the "pattern" mode when CONFIG_INIT_STACK_ALL is
enabled.

Developers have the possibility to opt-out of this feature on a
per-variable basis by using __attribute__((uninitialized)), but such
use should be well justified in comments.

Co-developed-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Alexander Potapenko <glider@google.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 085b7755 21-Apr-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc6


# dc4060a5 14-Apr-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc5


# a788b2ed 07-Apr-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build

After cross-compiling the kernel, "make mrproper" should be executed
with the proper ARCH= option. Otherwise, stale objects will remain
under arch/$(SRCARCH)/.

One bad scenario is like this:

$ make ARCH=arm defconfig all # cross-compile the kernel for arm
$ make mrproper # mrproper for host-arch (i.e. x86)
$ make ARCH=arm O=build_dir defconfig all

If you miss ARCH= for mrproper and cross-compile the kernel with O=
and ARCH= options, Kbuild will happily start to build, but may fail
due to stale objects in the srctree.

If $(srctree)/arch/$(SRCARCH)/include/generated/ exists, let's stop
the out-of-tree build. To detect this, mrproper should clean only
arch/$(SRCARCH)/include/generated/.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 24512795 07-Apr-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unneeded dependency for include/config/kernel.release

This is unneeded since commit 43fee2b23895 ("kbuild: do not redirect
the first prerequisite for filechk").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 43bd3a95 04-Apr-2019 Miroslav Benes <mbenes@suse.cz>

kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled

GCC 9 introduces a new option, -flive-patching. It disables certain
optimizations which could make a compilation unsafe for later live
patching of the running kernel.

The option is used only if CONFIG_LIVEPATCH is enabled and $(CC)
supports it.

Performance impact of the option was measured on three different
Intel machines - two bigger NUMA boxes and one smaller UMA box. Kernel
intensive (IO, scheduling, networking) benchmarks were selected, plus a
set of HPC workloads from NAS Parallel Benchmark. The tests were done on
upstream kernel 5.0-rc8 with openSUSE Leap 15.0 userspace.

The majority of the tests is unaffected. The only significant exception
is the scheduler section which suffers 1-3% degradation.

Evaluated-by: Giovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>


# 15ade5d2 07-Apr-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc4


# e83b9f55 02-Apr-2019 Andrii Nakryiko <andriin@fb.com>

kbuild: add ability to generate BTF type info for vmlinux

This patch adds new config option to trigger generation of BTF type
information from DWARF debuginfo for vmlinux and kernel modules through
pahole, which in turn relies on libbpf for btf_dedup() algorithm.

The intent is to record compact type information of all types used
inside kernel, including all the structs/unions/typedefs/etc. This
enables BPF's compile-once-run-everywhere ([0]) approach, in which
tracing programs that are inspecting kernel's internal data (e.g.,
struct task_struct) can be compiled on a system running some kernel
version, but would be possible to run on other kernel versions (and
configurations) without recompilation, even if the layout of structs
changed and/or some of the fields were added, removed, or renamed.

This is only possible if BPF loader can get kernel type info to adjust
all the offsets correctly. This patch is a first time in this direction,
making sure that BTF type info is part of Linux kernel image in
non-loadable ELF section.

BTF deduplication ([1]) algorithm typically provides 100x savings
compared to DWARF data, so resulting .BTF section is not big as is
typically about 2MB in size.

[0] http://vger.kernel.org/lpc-bpf2018.html#session-2
[1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>


# a9a49c2a 30-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build

KBUILD_SRC was conventionally used for some different purposes:
[1] To remember the source tree path
[2] As a flag to check if sub-make is already done
[3] As a flag to check if Kbuild runs out of tree

For [1], we do not need to remember it because the top Makefile
can compute it by $(realpath $(dir $(lastword $(MAKEFILE_LIST))))

[2] has been replaced with self-commenting 'sub_make_done'.

For [3], we can distinguish in-tree/out-of-tree by comparing
$(srctree) and '.'

This commit converts [3] to prepare for the KBUILD_SRC removal.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 25b146c5 30-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: allow Kbuild to start from any directory

Kbuild always runs in the top of the output directory.

If Make starts in the source directory with O=, it relocates the
working directory to the location specified by O=.

Also, users can start build from the output directory by using the
Makefile generated by scripts/mkmakefile.

With a little more effort, Kbuild will be able to start from any
directory path.

This commit allows to specify the source directory by using
the -f option.

For example, you can do:

$ cd path/to/output/dir
$ make -f path/to/source/dir/Makefile

Or, for the equivalent behavior, you can do:

$ make O=path/to/output/dir -f path/to/source/dir/Makefile

KBUILD_SRC is now deprecated.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kbingham@kernel.org>


# 6b1a9a02 30-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: pass $(MAKECMDGOALS) to sub-make as is

Manipulating $(MAKECMDGOALS) for sub-make seems odd to me.

[1] 'make O=foo sub-make' is turned into 'make O=foo', which builds
the default targets. It would make sense to terminate the build with:

*** No rule to make target 'sub-make'. Stop.

[2] 'make O=foo defconfig _all' is turned into 'make O=foo defconfig',
which changes the behavior.

Let's pass $(MAKECMDGOALS) as is.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0209987f 26-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix warning "overriding recipe for target 'Makefile'"

If you do "make Makefile" with GNU Make 3.x, the following warning
is displayed:

$ make Makefile
Makefile:165: warning: overriding recipe for target 'Makefile'
Makefile:51: warning: ignoring old recipe for target 'Makefile'
make[1]: Nothing to be done for 'Makefile'.
make: Nothing to be done for 'Makefile'.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 669e06b1 26-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move RETPOLINE flags below config-targets

When you run a "make *config" target, the retpoline compiler flags
are evaluated for nothing because the code is located above the
'ifeq ($(config-targets),1)'.

Move it a bit below to avoid unneeded computation in the Kconfig stage.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 79a3aaa7 31-Mar-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc3


# 156e7cbb 25-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not overwrite .gitignore in output directory

Commit 3a51ff344204 ("kbuild: gitignore output directory") seemed to
bother people who version-control output directories.

Andre Przywara says:
"Unfortunately this breaks my setup, because I keep a totally separate
git repository in my build directories to track (various versions of)
.config. So .gitignore there is carefully crafted to ignore most build
artefacts, but not .config, for instance."

Link: https://lkml.org/lkml/2019/3/22/1819
Reported-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>


# 221cc2d2 25-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: skip parsing pre sub-make code for recursion

When Make recurses to the top Makefile with sub-make-done unset,
the code block surrounded by 'ifneq ($(sub-make-done),1) ... endif'
is parsed multiple times. This happens for in-tree building of
include/config/auto.conf, *-pkg, etc. with GNU Make 4.x.

This is a slight regression by commit 688931a5ad4e ("kbuild: skip
sub-make for in-tree build with GNU Make 4.x") in terms of performance
since that code block contains one $(shell ...) invocation.

Fix it by exporting the variable irrespective of sub-make being run.
I renamed it because GNU Make cannot properly export variables
containing hyphens. This is probably a bug of GNU Make, and the issue
in Kbuild had already been reported by commit 2bfbe7881ee0 ("kbuild:
Do not use hyphen in exported variable name").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 056d28d1 25-Mar-2019 Rolf Eike Beer <eb@emlix.com>

objtool: Query pkg-config for libelf location

If it is not in the default location, compilation fails at several points.

Signed-off-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.com


# 8c2ffd91 24-Mar-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc2


# 688931a5 18-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: skip sub-make for in-tree build with GNU Make 4.x

Commit 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
annoyed people who want to wrap the top Makefile with GNUmakefile
to customize it for their use.

On second thought, we do not need to run the sub-make for in-tree
build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens
on GNU Make 3.x.

With this commit, people will get back their workflow, and the Debian
make-kpkg will still work.

Fixes: 2b50f7ab6368 ("kbuild: add workaround for Debian make-kpkg")
Reported-by: Andreas Schwab <schwab@suse.de>
Reported-by: David Howells <dhowells@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Andreas Schwab <schwab@suse.de>
Tested-by: David Howells <dhowells@redhat.com>


# a75bb4eb 18-Mar-2019 Matthias Kaehlcke <mka@chromium.org>

Revert "kbuild: use -Oz instead of -Os when using clang"

The clang option -Oz enables *aggressive* optimization for size,
which doesn't necessarily result in smaller images, but can have
negative impact on performance. Switch back to the less aggressive
-Os.

This reverts commit 6748cb3c299de1ffbe56733647b01dbcc398c419.

Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9e98c678 17-Mar-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.1-rc1


# 037fc336 16-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: force all architectures except um to include mandatory-y

Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes
the common Kbuild.asm file. Factor out the duplicated include directives
to scripts/Makefile.asm-generic so that no architecture would opt out
of the mandatory-y mechanism.

um is not forced to include mandatory-y since it is a very exceptional
case which does not support UAPI.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0c22be07 14-Mar-2019 Douglas Anderson <dianders@chromium.org>

kbuild: Make NOSTDINC_FLAGS a simply expanded variable

During a simple no-op (nothing changed) build I saw 39 invocations of
the C compiler with the argument "-print-file-name=include". We don't
need to call the C compiler 39 times for this--one time will suffice.

Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid
this since there doesn't appear to be any reason it should be
recursively expanded.

On my build this shaved ~400 ms off my "no-op" build.

Note that the recursive expansion seems to date back to the (really
old) commit e8f5bdb02ce0 ("[PATCH] Makefile include path ordering").
It's a little unclear to me if the point of that patch was to switch
the variable to be recursively expanded (which it did) or to avoid
directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because
someone else (out of tree?) was setting it. I presume later since if
the only goal was to switch to recursive expansion the patch would
have just removed the ":".

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2b50f7ab 08-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add workaround for Debian make-kpkg

Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top
Makefile for old Make versions"), make-kpkg is not working.

make-kpkg directly includes the top Makefile of Linux kernel, and
appends some debian_* targets.

/usr/share/kernel-package/ruleset/kernel_version.mk:

# Include the kernel makefile
override dot-config := 1
include Makefile
dot-config := 1

I did not know the kernel Makefile was used in that way, and it is
hard to guarantee the behavior when the kernel Makefile is included
by another Makefile from a different project.

It looks like Debian Stretch stopped providing make-kpkg. Maybe it is
obsolete and being replaced with 'make deb-pkg' etc. but still widely
used.

This commit adds a workaround; if the top Makefile is included by
another Makefile, skip sub-make in order to make the main part visible.
'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but
Debian/Ubuntu is already using newer versions.

The effect of this commit:

Debian 8 (Jessie) : Fixed
Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided
Ubuntu 14.04 LTS : NOT Fixed
Ubuntu 16.04 LTS : Fixed
Ubuntu 18.04 LTS : Fixed

This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81,
but its support will end in Apr 2019, which is before the Linux v5.1
release.

I added warning so that nobody would try to include the top Makefile.

Fixes: 3812b8c5c5d5 ("kbuild: make -r/-R effective in top Makefile for old Make versions")
Reported-by: Liz Zhang <lizzha@microsoft.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Lili Deng <v-lide@microsoft.com>
Cc: Manoj Srivastava <srivasta@debian.org>


# 9250d20e 04-Mar-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove scripts/basic/% build target

This build rule was introduced by commit cd05e6bdc600 ("[PATCH]
kbuild: fix split-include dependency") to handle the dependency of
scripts/basic/split-include.

Now, fixdep is the only tool in scripts/basic/, and this rule is
no longer used.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b89f25ea 04-Mar-2019 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: use -Werror=implicit-... instead of -Werror-implicit-...

The flag '-Werror-implicit-function-declaration', present in GCC 2.95,
stopped to be documented in GCC 4.3, replaced by the more generic
'-Werror=...' form.

So, use the equivalent '-Werror=implicit-function-declaration' instead.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 54b598a8 28-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove commented-out INITRD_COMPRESS

This code has been commented out since commit b7000adef17a
("Don't set the INITRD_COMPRESS environment variable automatically").

Clean it up now.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 1c163f4c 03-Mar-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0


# 9d937444 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move -gsplit-dwarf, -gdwarf-4 option tests to Kconfig

CONFIG_DEBUG_INFO_SPLIT and CONFIG_DEBUG_INFO_DWARF4 enable extra
dwarf options if supported. You never know if they are really enabled
since Makefile may silently turn them off.

The actual behavior will match to the kernel configuration by
testing those compiler flags in the Kconfig stage.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 05850719 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move ".config not found!" message from Kconfig to Makefile

If you run "make" in a pristine source tree, currently Kbuild will
start to build Kconfig to let it show the error message.

It would be more straightforward to check it in Makefile and let
it fail immediately.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9390dff6 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing

If include/config/auto.conf.cmd is lost for some reasons, it is not
self-healing, so the top Makefile misses to run syncconfig.
Move include/config/auto.conf.cmd to the target side.

I used a pattern rule instead of a normal rule here although it is
a bit gross.

If the rule were written with a normal rule like this,

include/config/auto.conf \
include/config/auto.conf.cmd \
include/config/tristate.conf: $(KCONFIG_CONFIG)
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig

... syncconfig would be executed per target.

Using a pattern rule makes sure that syncconfig is executed just once
because Make assumes the recipe will create all of the targets.

Here is a quote from the GNU Make manual [1]:

"Pattern rules may have more than one target. Unlike normal rules,
this does not act as many different rules with the same prerequisites
and recipe. If a pattern rule has multiple targets, make knows that
the rule's recipe is responsible for making all of the targets. The
recipe is executed only once to make all the targets. When searching
for a pattern rule to match a target, the target patterns of a rule
other than the one that matches the target in need of a rule are
incidental: make worries only about giving a recipe and prerequisites
to the file presently in question. However, when this file's recipe is
run, the other targets are marked as having been updated themselves."

[1]: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6b12de69 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: simplify single target rules

The dependency will be checked anyway after Kbuild descends into a
sub-directory. Skip object/source dependency checks in top Makefile.

VPATH can be simpler since the top Makefile no longer checks the
presence of the source file, which is located in in the external
module directory.

One good thing is, it can compile an object from a generated source
file.

$ make crypto/rsapubkey.asn1.o
...
ASN.1 crypto/rsapubkey.asn1.c
CC crypto/rsapubkey.asn1.o

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b999923c 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove empty rules for makefiles

The previous commit made 'MAKEFLAGS += -rR' effective in the top
Makefile regardless of O= option, GNU Make versions.

The top Makefile does not need to cancel implicit rules for makefiles.

There is still one place where an empty rule is useful. Since -rR is
effective only after sub-make, GNU Make would try implicit rules to
update the top Makefile. Although it is not a big overhead, cancel it
just in case.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 3812b8c5 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make -r/-R effective in top Makefile for old Make versions

Adding -rR to MAKEFLAGS is important because we do not want to
be bothered by built-in implicit rules or variables.

One problem that used to exist in older GNU Make versions is

MAKEFLAGS += -rR

... does not become effective in the current Makefile. When you are
building with O= option, it becomes effective in the top Makefile
since it recurses via 'sub-make' target. Otherwise, the top Makefile
tries implicit rules. That is why we explicitly add empty rules for
Makefiles, but we often miss to do that.

In fact, adding -d option to older GNU Make versions shows it is
trying a bunch of implicit pattern rules.

Considering target file `scripts/Makefile.kcov'.
Looking for an implicit rule for `scripts/Makefile.kcov'.
Trying pattern rule with stem `Makefile.kcov'.
Trying implicit prerequisite `scripts/Makefile.kcov.o'.
Trying pattern rule with stem `Makefile.kcov'.
Trying implicit prerequisite `scripts/Makefile.kcov.c'.
Trying pattern rule with stem `Makefile.kcov'.
Trying implicit prerequisite `scripts/Makefile.kcov.cc'.
Trying pattern rule with stem `Makefile.kcov'.
Trying implicit prerequisite `scripts/Makefile.kcov.C'.
...

This issue was fixed by GNU Make commit 58dae243526b ("[Savannah #20501]
Handle adding -r/-R to MAKEFLAGS in the makefile"). So, it is no longer
a problem if you use GNU Make 4.0 or later. However, older versions are
still widely used.

So, I decided to patch the kernel Makefile to invoke sub-make regardless
of O= option. This will allow further cleanups.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f47a23ce 22-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move tools_silent to a more relevant place

This would disturb the change the sub-make part. Move it near the
tools/ target.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b303c6df 20-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig

Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched
various false positives:

- commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized when building
with -Os") turned off this option for -Os.

- commit 815eb71e7149 ("Kbuild: disable 'maybe-uninitialized' warning
for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for
CONFIG_PROFILE_ALL_BRANCHES

- commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning
for "make W=1"") turned off this option for GCC < 4.9
Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903

I think this looks better by shifting the logic from Makefile to Kconfig.

Link: https://github.com/ClangBuiltLinux/linux/issues/350
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# 88110713 19-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: hardcode genksyms path and remove GENKSYMS variable

The genksyms source was integrated into the kernel tree in 2003.

I do not expect anybody still using the external /sbin/genksyms.
Kbuild does not need to provide the ability to override GENKSYMS.

Let's remove the GENKSYMS variable, and use the hardcoded path.

Since it occurred in the pre-git era, I attached the commit message
in case somebody is interested in the historical background.

| Author: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
| Date: Wed Feb 19 04:17:28 2003 -0600
|
| kbuild: [PATCH] put genksyms in scripts dir
|
| This puts genksyms into scripts/genksyms/.
|
| genksyms used to be maintained externally, though the only possible user
| was the kernel build. Moving it into the kernel sources makes it easier to
| keep it uptodate, like for example updating it to generate linker scripts
| directly instead of postprocessing the generated header file fragments
| with sed, as we do currently.
|
| Also, genksyms does not handle __typeof__, which needs to be fixed since
| some of the exported symbol in the kernel are defined using __typeof__.
|
| (Rusty Russell/me)

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8d2e5200 19-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: create symlink to vmlinux-gdb.py in scripts_gdb target

It is weird to create gdb stuff as a side-effect of vmlinux.

Move it to a more relevant place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>


# 1e5ff84f 19-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

scripts/gdb: do not descend into scripts/gdb from scripts

Currently, Kbuild descends from scripts/Makefile to scripts/gdb/Makefile
just for creating symbolic links, but it does not need to do it so early.

Merge the two descending paths to simplify the code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>


# 67274c08 19-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

scripts/gdb: delay generation of gdb constants.py

scripts/gdb/linux/constants.py is never used in the kernel build
process. There is no good reason to create it so early.

Get it out of the 'prepare' stage.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>


# 5908e6b7 24-Feb-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc8


# 6d3c94e4 13-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: turn '/' into an alias of './'

Commit 06300b21f4c7 ("kbuild: support building individual files for
external modules") introduced the '/' target. It works only for
external modules to build all .o files, but skip the modpost stage.

However, 'make /' looks a bit weird to me. 'make ./' is more sensible
if you want to build all objects under the current directory, and it
works as expected.

Let's change '/' into a phony target that is an alias of './', but
I may feel like deprecating it in the future.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 648ad9b1 13-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: set KBUILD_MODULES=1 all the time for single target %/

It is fine to set KBUILD_MODULES=1 when CONFIG_MODULES is disabled.
It is actually how "make allnoconfig all" works.

On the other hand, KBUILD_MODULES=1 is unneeded for the %.ko pattern.
It is just a matter of whether modules.order is generated or not.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ad15006c 11-Feb-2019 Nick Desaulniers <ndesaulniers@google.com>

kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD

This causes an issue when trying to build with `make LD=ld.lld` if
ld.lld and the rest of your cross tools aren't in the same directory
(ex. /usr/local/bin) (as is the case for Android's build system), as the
GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point
where LLVM tools are, not GCC/binutils tools are located.

Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by
binutils for which LLVM does not provide a substitute for, such as
elfedit.

Fixes: 785f11aa595b ("kbuild: Add better clang cross build support")
Link: https://github.com/ClangBuiltLinux/linux/issues/341
Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 1e88e415 09-Feb-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: Disable extra debugging info in .s output

Modern gcc adds view assignments, reset assertion checking in .loc
directives and a couple more additional debug markers, which clutters
the asm output unnecessarily:

For example:

bsp_resume:
.LFB3466:
.loc 1 1868 1 is_stmt 1 view -0
.cfi_startproc
.loc 1 1869 2 view .LVU73
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 14 is_stmt 0 view .LVU74
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 5 view .LVU75
testq %rax, %rax # _2
je .L8 #,
.loc 1 1870 3 is_stmt 1 view .LVU76
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax

or
.loc 2 57 9 view .LVU478
.loc 2 57 9 view .LVU479
.loc 2 57 9 view .LVU480
.loc 2 57 9 view .LVU481
.LBB1385:
.LBB1383:
.LBB1379:
.LBB1377:
.LBB1375:
.loc 2 57 9 view .LVU482
.loc 2 57 9 view .LVU483
movl %edi, %edx # cpu, cpu
.LVL87:
.loc 2 57 9 is_stmt 0 view .LVU484

That MOV in there is drowned in debugging information and latter makes
it hard to follow the asm. And that DWARF info is not really needed for
asm output staring.

Disable the debug information generation which clutters the asm output
unnecessarily:

bsp_resume:
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
testq %rax, %rax # _2
je .L8 #,
# arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
.L8:
# arch/x86/kernel/cpu/common.c:1871: }
rep ret
.size bsp_resume, .-bsp_resume

[ bp: write commit message. ]

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>


# 3a51ff34 03-Feb-2019 Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>

kbuild: gitignore output directory

When compiling into output directory using O=, many files
created under KBUILD_OUTPUT that git considers
as new ones; git clients, ex. "git gui" lists it, and it clutters
file list making it difficult to see what was really changed

Generate .gitignore in output directory that ignores all
its content

Signed-off-by: Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a3b22b9f 17-Feb-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc7


# d1393711 10-Feb-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc6


# 8834f560 03-Feb-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc5


# 4f1c1008 17-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove meaningless prepare2 target

There is no build order among the following:
prepare3
outputmakefile
asm-generic
$(version_h)
$(autoksyms_h)
include/generated/utsrelease.h

It is meaningless to insert the prepare2 target between the first
three and the last three.

The comment says, "prepare2 creates a makefile if using a separate
output directory." Let me explain it more precisely. The prepare
targets cannot be executed without the .config file. Because the
configuration targets depend on the outputmakefile target, the
generated makefile is already there before the parepare2 is run.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d151e971 16-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: merge KBUILD_VMLINUX_{INIT,MAIN} into KBUILD_VMLINUX_OBJS

The top Makefile does not need to export KBUILD_VMLINUX_INIT and
KBUILD_VMLINUX_MAIN separately.

Put every built-in.a into KBUILD_VMLINUX_OBJS. The order of
$(head-y), $(init-y), $(core-y), ... is still retained.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f17b5f06 27-Jan-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc4


# f96182e9 11-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

firmware_loader: move firmware/ to drivers/base/firmware_loader/builtin/

Currently, the 'firmware' directory only contains a single Makefile
to embed extra firmware into the kernel.

Move it to the more relevant place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 49a57857 20-Jan-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc3


# e00d8880 15-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: mark prepare0 as PHONY to fix external module build

Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
caused kernel panic on PowerPC when an external module is used with
CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
for the external module build.

Commit e07db28eea38 ("kbuild: fix single target build for external
module") turned it into a build error because the 'prepare' target is
now executed but the 'prepare0' target is missing for the external
module build.

External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is
also broken in the same way.

Move 'PHONY += prepare0' to the common place. GNU Make is fine with
missing rule for phony targets. I also removed the comment which is
wrong irrespective of this commit.

I minimize the change so it can be easily backported to 4.20.x

To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target
build for external module"), and then this commit.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891
Fixes: e07db28eea38 ("kbuild: fix single target build for external module")
Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support")
Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries")
Cc: linux-stable <stable@vger.kernel.org> # v4.20
Reported-by: Samuel Holland <samuel@sholland.org>
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>


# b421b8a6 14-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unused archmrproper

No one uses archmrproper.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 1c7fc5cb 13-Jan-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc2


# bfeffd15 06-Jan-2019 Linus Torvalds <torvalds@linux-foundation.org>

Linux 5.0-rc1


# f7de64b7 02-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove unnecessary stubs for archheader and archscripts

Make simply skips a missing rule when it is marked as .PHONY.
Remove the dummy targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ba97df45 02-Jan-2019 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: use assignment instead of define ... endef for filechk_* rules

You do not have to use define ... endef for filechk_* rules.

For simple cases, the use of assignment looks cleaner, IMHO.

I updated the usage for scripts/Kbuild.include in case somebody
misunderstands the 'define ... endif' is the requirement.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>


# ad774086 31-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: change filechk to surround the given command with { }

filechk_* rules often consist of multiple 'echo' lines. They must be
surrounded with { } or ( ) to work correctly. Otherwise, only the
string from the last 'echo' would be written into the target.

Let's take care of that in the 'filechk' in scripts/Kbuild.include
to clean up filechk_* rules.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# e9666d10 30-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

jump_label: move 'asm goto' support test to Kconfig

Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label".

The jump label is controlled by HAVE_JUMP_LABEL, which is defined
like this:

#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
# define HAVE_JUMP_LABEL
#endif

We can improve this by testing 'asm goto' support in Kconfig, then
make JUMP_LABEL depend on CC_HAS_ASM_GOTO.

Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will
match to the real kernel capability.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>


# 8fe28cb5 23-Dec-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20


# ef7cfd00 17-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix false positive warning/error about missing libelf

For the same reason as commit 25896d073d8a ("x86/build: Fix compiler
support check for CONFIG_RETPOLINE"), you cannot put this $(error ...)
into the parse stage of the top Makefile.

Perhaps I'd propose a more sophisticated solution later, but this is
the best I can do for now.

Link: https://lkml.org/lkml/2017/12/25/211
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reported-by: Qian Cai <cai@lca.pw>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Qian Cai <cai@lca.pw>


# 6ac38934 19-Dec-2018 Ingo Molnar <mingo@kernel.org>

Revert "kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs"

This reverts commit 77b0bf55bc675233d22cd5df97605d516d64525e.

See this commit for details about the revert:

e769742d3584 ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"")

Conflicts:
arch/x86/Makefile

Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Borislav Petkov <bp@alien8.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Juergen Gross <jgross@suse.com>
Cc: Richard Biener <rguenther@suse.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Nadav Amit <namit@vmware.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 7566ec39 16-Dec-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc7


# 61a0902a 14-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Werror=implicit-int flag unconditionally

This flag is documented in the GCC 4.6 manual, and recognized by
Clang as well. Let's rip off the cc-option switch.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# eeb5687a 14-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Werror=strict-prototypes flag unconditionally

-Wstrict-prototypes is added to KBUILD_CFLAGS first, then overridden
by -Werror=strict-prototypes later.

Let's add -Werror=strict-prototypes unconditionally because it is
supported by GCC 4.6, and also by Clang.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 42a92bcc 14-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -fno-PIE flag unconditionally

This flag is documented in the GCC 4.6 manual, and recognized by
Clang as well. Let's rip off the cc-option switch.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# 7d0e5c20 05-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: refactor Makefile.asm-generic

- Use conventional $(MAKE) $(asm-generic)=<dir> style
for directory descending

- Remove unneeded FORCE since "all" is a phony target

- Remove unneeded "_dummy :=" assignment

- Skip $(shell mkdir ...) when headers exist in the directory

- Misc cleanups

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>


# 4f0e3a57 06-Sep-2018 Rob Herring <robh@kernel.org>

kbuild: Add support for DT binding schema checks

This adds the build infrastructure for checking DT binding schema
documents and validating dts files using the binding schema.

Check DT binding schema documents:
make dt_binding_check

Build dts files and check using DT binding schema:
make dtbs_check

Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
use for validation. This makes it easier to find and fix errors
generated by a specific schema.

Currently, the validation targets are separate from a normal build to
avoid a hard dependency on the external DT schema project and because
there are lots of warnings generated.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-doc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>


# 40e020c1 09-Dec-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc6


# 257edce6 05-Dec-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: exploit parallel building for CONFIG_HEADERS_CHECK

When CONFIG_HEADERS_CHECK is enabled, the headers_check is executed
as a serialized task in the vmlinux recipe.

Make it independent of vmlinux so that parallel building can process
the headers_check and other build targets simultaneously.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 25956467 02-Dec-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc5


# 392885ee 29-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: let fixdep directly write to .*.cmd files

Currently, fixdep writes dependencies to .*.tmp, which is renamed to
.*.cmd after everything succeeds. This is a very safe way to avoid
corrupted .*.cmd files. The if_changed_dep has carried this safety
mechanism since it was added in 2002.

If fixdep fails for some reasons or a user terminates the build while
fixdep is running, the incomplete output from the fixdep could be
troublesome.

This is my insight about some bad scenarios:

[1] If the compiler succeeds to generate *.o file, but fixdep fails
to write necessary dependencies to .*.cmd file, Make will miss
to rebuild the object when headers or CONFIG options are changed.
In this case, fixdep should not generate .*.cmd file at all so
that 'arg-check' will surely trigger the rebuild of the object.

[2] A partially constructed .*.cmd file may not be a syntactically
correct makefile. The next time Make runs, it would include it,
then fail to parse it. Once this happens, 'make clean' is be the
only way to fix it.

In fact, [1] is no longer a problem since commit 9c2af1c7377a ("kbuild:
add .DELETE_ON_ERROR special target"). Make deletes a target file on
any failure in its recipe. Because fixdep is a part of the recipe of
*.o target, if it fails, the *.o is deleted anyway. However, I am a
bit worried about the slight possibility of [2].

So, here is a solution. Let fixdep directly write to a .*.cmd file,
but allow makefiles to include it only when its corresponding target
exists.

This effectively reverts commit 2982c953570b ("kbuild: remove redundant
$(wildcard ...) for cmd_files calculation"), and commit 00d78ab2ba75
("kbuild: remove dead code in cmd_files calculation in top Makefile")
because now we must check the presence of targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ce2fd53a 28-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile

Now that 'archprepare' depends on 'scripts', Kbuild can descend into
scripts/gcc-plugins in a more standard way.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# 059bc9fc 28-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make 'archprepare' depend on 'scripts'

Before start descending, Kbuild needs to run 'prepare' and 'scripts',
which has been orthogonal to each other.

Going forward, let's consider 'scripts' is a part of the preparation.
This will allow more cleanups.

Move 'scripts' to the prerequisite of 'archprepare', where UML starts
compiling target *.c files.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 60df1aee 28-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move modpost out of 'scripts' target

I am eagar to build under the scripts/ directory only with $(HOSTCC),
but scripts/mod/ highly depends on the $(CC) and target arch headers.
That it why the 'scripts' target must depend on 'asm-generic',
'gcc-plugins', and $(autoksyms_h).

Move it to the 'prepare0' stage. I know this is a cheesy workaround,
but better than the current situation.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 65bba042 28-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix UML build error with CONFIG_GCC_PLUGINS

UML fails to build with CONFIG_GCC_PLUGINS=y.

$ make -s ARCH=um mrproper
$ make -s ARCH=um allmodconfig
$ make ARCH=um
UPD include/generated/uapi/linux/version.h
WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/x86/include/generated/uapi/asm/poll.h
WRAP arch/x86/include/generated/asm/dma-contiguous.h
WRAP arch/x86/include/generated/asm/early_ioremap.h
WRAP arch/x86/include/generated/asm/export.h
WRAP arch/x86/include/generated/asm/mcs_spinlock.h
WRAP arch/x86/include/generated/asm/mm-arch-hooks.h
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h
SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h
HOSTCC scripts/unifdef
CC arch/x86/um/user-offsets.s
cc1: error: cannot load plugin ./scripts/gcc-plugins/cyc_complexity_plugin.so
./scripts/gcc-plugins/cyc_complexity_plugin.so: cannot open shared object file: No such file or directory
cc1: error: cannot load plugin ./scripts/gcc-plugins/structleak_plugin.so
./scripts/gcc-plugins/structleak_plugin.so: cannot open shared object file: No such file or directory
cc1: error: cannot load plugin ./scripts/gcc-plugins/latent_entropy_plugin.so
./scripts/gcc-plugins/latent_entropy_plugin.so: cannot open shared object file: No such file or directory
cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so
./scripts/gcc-plugins/randomize_layout_plugin.so: cannot open shared object file: No such file or directory
make[1]: *** [scripts/Makefile.build;119: arch/x86/um/user-offsets.s] Error 1
make: *** [arch/um/Makefile;152: arch/x86/um/user-offsets.s] Error 2

Reorder the preparation stage (with cleanups) to make sure gcc-plugins
is built before descending to arch/x86/um/.

Fixes: 6b90bd4ba40b ("GCC plugin infrastructure")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# e07db28e 21-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix single target build for external module

Building a single target in an external module fails due to missing
.tmp_versions directory.

For example,

$ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o

will fail in the following way:

CC [M] /home/masahiro/foo/foo.o
/bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent

This is because $(cmd_crmodverdir) is executed only before building
/, %/, %.ko single targets of external modules. Create .tmp_versions
in the 'prepare' target.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0126be38 20-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: announce removal of SUBDIRS if used

SUBDIRS has been kept as a backward compatibility since
commit ("[PATCH] kbuild: external module support") in 2002.

We do not need multiple ways to do the same thing, so I will remove
SUBDIRS after the Linux 5.3 release. I cleaned up in-tree code, and
updated the document so that nobody would try to use it.

Meanwhile, display the following warning if SUBDIRS is used.

Makefile:189: ================= WARNING ================
Makefile:190: 'SUBDIRS' will be removed after Linux 5.3
Makefile:191: Please use 'M=' or 'KBUILD_EXTMOD' instead
Makefile:192: ==========================================

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> # for scx200_docflash.c
Acked-by: Guenter Roeck <linux@roeck-us.net> # for scx200_wdt.c


# 2e6e902d 25-Nov-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc4


# 9ff01193 18-Nov-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc3


# 3bd98050 11-Nov-2018 Joel Stanley <joel@jms.id.au>

Makefile: Export clang toolchain variables

The powerpc makefile will use these in it's boot wrapper.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 238bcbc4 05-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: consolidate Clang compiler flags

Collect basic Clang options such as --target, --prefix, --gcc-toolchain,
-no-integrated-as into a single variable CLANG_FLAGS so that it can be
easily reused in other parts of Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Greg Hackmann <ghackmann@google.com>


# dbe27a00 05-Nov-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -no-integrated-as Clang option unconditionally

We are still a way off the Clang's integrated assembler support for
the kernel. Hence, -no-integrated-as is mandatory to build the kernel
with Clang. If you had an ancient version of Clang that does not
recognize this option, you would not be able to compile the kernel
anyway.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# ccda4af0 11-Nov-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc2


# 65102238 04-Nov-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.20-rc1


# 99516742 30-Oct-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove cc-name variable

There is one more user of $(cc-name) in the top Makefile. It is supposed
to detect Clang before invoking Kconfig, so it should still be there
in the $(shell ...) form. All the other users of $(cc-name) have been
replaced with $(CONFIG_CC_IS_CLANG). Hence, scripts/Kbuild.include does
not need to define cc-name any more.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 076f421d 30-Oct-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: replace cc-name test with CONFIG_CC_IS_CLANG

Evaluating cc-name invokes the compiler every time even when you are
not compiling anything, like 'make help'. This is not efficient.

The compiler type has been already detected in the Kconfig stage.
Use CONFIG_CC_IS_CLANG, instead.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Paul Burton <paul.burton@mips.com> (MIPS)
Acked-by: Joel Stanley <joel@jms.id.au>


# 84df9525 22-Oct-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.19


# 9df3e7a7 01-Oct-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Wno-unused-but-set-variable flag unconditionally

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

This flag was added by GCC 4.6, and it is recognized by ICC as well.

It is true that Clang does not support this flag but this commit is
just touching the else part of the "ifeq ($(cc-name),clang)" check.
Hence, Clang build is not affected.

Let's rip off the cc-disable-warning switch, and see if somebody
complains about it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>


# a33e7ae2 01-Oct-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Wdeclaration-after-statement flag unconditionally

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

This flag has been here since the pre-git era. It is documented in
the GCC 4.6 manual, and it is recognized by Clang and ICC as well.

Let's rip off the cc-option switch, and see if somebody complains
about it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# fb073a4b 01-Oct-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add -Wno-pointer-sign flag unconditionally

We have raised the compiler requirement from time to time.
With commit cafa0010cd51 ("Raise the minimum required gcc version
to 4.6"), the minimum for GCC is 4.6 now.

The -Wno-pointer-sign has been here since the pre-git era. It is
documented in the GCC 4.6 manual, and it is recognized by Clang
and ICC as well.

Let's rip off the cc-disable-warning switch, and see if somebody
complains about it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>


# 35a7f35a 14-Oct-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.19-rc8


# 0bb95f80 25-Jun-2018 Kees Cook <keescook@chromium.org>

Makefile: Globally enable VLA warning

Now that Variable Length Arrays (VLAs) have been entirely removed[1]
from the kernel, enable the VLA warning globally. The only exceptions
to this are the KASan an UBSan tests which are explicitly checking that
VLAs trigger their respective tests.

[1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Airlie <airlied@linux.ie>
Cc: linux-kbuild@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kees Cook <keescook@chromium.org>


# 0238df64 07-Oct-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.19-rc7


# 4fd61277 18-Sep-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not pass $(objtree) to scripts/mkmakefile

Since $(objtree) is always '.', it is not useful to pass it to
scripts/mkmakefile. I assume nobody wants to run this script directly.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 77ec0c20 18-Sep-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile

Neither VERSION nor PATCHLEVEL is used in any useful way.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 80463f1b 14-Sep-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add --include-dir flag only for out-of-tree build

The --include-dir flag is used to include check-in Makefiles from
$(objtree) without $(srctree)/ prefix. Obviously, this is unneeded
for in-tree build. Add the flag just before changing the working
directory.

This becomes effective after invoking sub-make. Add a little bit
comments about it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 77b0bf55 03-Oct-2018 Nadav Amit <namit@vmware.com>

kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs

Using macros in inline assembly allows us to work around bugs
in GCC's inlining decisions.

Compile macros.S and use it to assemble all C files.
Currently only x86 will use it.

Background:

The inlining pass of GCC doesn't include an assembler, so it's not aware
of basic properties of the generated code, such as its size in bytes,
or that there are such things as discontiuous blocks of code and data
due to the newfangled linker feature called 'sections' ...

Instead GCC uses a lazy and fragile heuristic: it does a linear count of
certain syntactic and whitespace elements in inlined assembly block source
code, such as a count of new-lines and semicolons (!), as a poor substitute
for "code size and complexity".

Unsurprisingly this heuristic falls over and breaks its neck whith certain
common types of kernel code that use inline assembly, such as the frequent
practice of putting useful information into alternative sections.

As a result of this fresh, 20+ years old GCC bug, GCC's inlining decisions
are effectively disabled for inlined functions that make use of such asm()
blocks, because GCC thinks those sections of code are "large" - when in
reality they are often result in just a very low number of machine
instructions.

This absolute lack of inlining provess when GCC comes across such asm()
blocks both increases generated kernel code size and causes performance
overhead, which is particularly noticeable on paravirt kernels, which make
frequent use of these inlining facilities in attempt to stay out of the
way when running on baremetal hardware.

Instead of fixing the compiler we use a workaround: we set an assembly macro
and call it from the inlined assembly block. As a result GCC considers the
inline assembly block as a single instruction. (Which it often isn't but I digress.)

This uglifies and bloats the source code - for example just the refcount
related changes have this impact:

Makefile | 9 +++++++--
arch/x86/Makefile | 7 +++++++
arch/x86/kernel/macros.S | 7 +++++++
scripts/Kbuild.include | 4 +++-
scripts/mod/Makefile | 2 ++
5 files changed, 26 insertions(+), 3 deletions(-)

Yay readability and maintainability, it's not like assembly code is hard to read
and maintain ...

We also hope that GCC will eventually get fixed, but we are not holding
our breath for that. Yet we are optimistic, it might still happen, any decade now.

[ mingo: Wrote new changelog describing the background. ]

Tested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Nadav Amit <namit@vmware.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kbuild@vger.kernel.org
Link: http://lkml.kernel.org/r/20181003213100.189959-3-namit@vmware.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 37c8a5fa 10-Jan-2018 Rob Herring <robh@kernel.org>

kbuild: consolidate Devicetree dtb build rules

There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Paul Burton <paul.burton@mips.com>
Acked-by: Ley Foon Tan <ley.foon.tan@intel.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Chris Zankel <chris@zankel.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: linux-kbuild@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Cc: linux-mips@linux-mips.org
Cc: nios2-dev@lists.rocketboards.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-xtensa@linux-xtensa.org
Signed-off-by: Rob Herring <robh@kernel.org>


# 17b57b18 30-Sep-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.19-rc6


# 6bf4ca7f 23-Sep-2018 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Linux 4.19-rc5


# ef8c4ed9 17-Sep-2018 Stefan Agner <stefan@agner.ch>

kbuild: allow to use GCC toolchain not in Clang search path

When using a GCC cross toolchain which is not in a compiled in
Clang search path, Clang reverts to the system assembler and
linker. This leads to assembler or linker errors, depending on
which tool is first used for a given architecture.

It seems that Clang is not searching $PATH for a matching
assembler or linker.

Make sure that Clang picks up the correct assembler or linker by
passing the cross compilers bin directory as search path.

This allows to use Clang provided by distributions with GCC
toolchains not in /usr/bin.

Link: https://github.com/ClangBuiltLinux/linux/issues/78
Signed-off-by: Stefan Agner <stefan@agner.ch>
Reviewed-and-tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7876320f 16-Sep-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.19-rc4


# 00d78ab2 12-Sep-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove dead code in cmd_files calculation in top Makefile

Nobody sets 'targets' in the top-level Makefile or arch/*/Makefile,
hence $(targets) is empty.

$(wildcard .*.cmd) will do for including the .vmlinux.cmd file.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 25815cf5 12-Sep-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: hide most of targets when running config or mixed targets

When mixed/config targets are being processed, the top Makefile
does not need to parse the rest of targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b1f4ff74 10-Sep-2018 Paulo Zanoni <paulo.r.zanoni@intel.com>

tracing/Makefile: Fix handling redefinition of CC_FLAGS_FTRACE

As a Kernel developer, I make heavy use of "make targz-pkg" in order
to locally compile and remotely install my development Kernels. The
nice feature I rely on is that after a normal "make", "make targz-pkg"
only generates the tarball without having to recompile everything.

That was true until commit f28bc3c32c05 ("tracing: Handle
CC_FLAGS_FTRACE more accurately"). After it, running "make targz-pkg"
after "make" will recompile the whole Kernel tree, making my
development workflow much slower.

The Kernel is choosing to recompile everything because it claims the
command line has changed. A diff of the .cmd files show a repeated
-mfentry in one of the files. That is because "make targz-pkg" calls
"make modules_install" and the environment is already populated with
the exported variables, CC_FLAGS_FTRACE being one of them. Then,
-mfentry gets duplicated because it is not protected behind an ifndef
block, like -pg.

To complicate the problem a little bit more, architectures can define
their own version CC_FLAGS_FTRACE, so our code not only has to
consider recursive Makefiles, but also architecture overrides.

So in this patch we move CC_FLAGS_FTRACE up and unconditionally
define it to -pg. Then we let the architecture Makefiles possibly
override it, and finally append the extra options later. This ensures
the variable is always fully redefined at each invocation so recursive
Makefiles don't keep appending, and hopefully it maintains the
intended behavior on how architectures can override the defaults..

Thanks Steven Rostedt and Vasily Gorbik for the help on this
regression.

Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: linux-kbuild@vger.kernel.org
Fixes: commit f28bc3c32c05 ("tracing: Handle CC_FLAGS_FTRACE more accurately")
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


# 11da3a7f 09-Sep-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.19-rc3


# b2d35fa5 03-Sep-2018 Anders Roxell <anders.roxell@linaro.org>

selftests: add headers_install to lib.mk

If the kernel headers aren't installed we can't build all the tests.
Add a new make target rule 'khdr' in the file lib.mk to generate the
kernel headers and that gets include for every test-dir Makefile that
includes lib.mk If the testdir in turn have its own sub-dirs the
top_srcdir needs to be set to the linux-rootdir to be able to generate
the kernel headers.

Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Reviewed-by: Fathi Boudra <fathi.boudra@linaro.org>
Signed-off-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>


# 57361846 02-Sep-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.19-rc2


# 217c3e01 30-Aug-2018 Stephen Rothwell <sfr@canb.auug.org.au>

disable stringop truncation warnings for now

They are too noisy

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 5b394b2d 26-Aug-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.19-rc1


# d503ac53 23-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: rename LDFLAGS to KBUILD_LDFLAGS

Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.

Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.

Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add
additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.

For some reason, LDFLAGS was not renamed.

Using a well-known variable like LDFLAGS may result in accidental
override of the variable.

Kbuild generally uses KBUILD_ prefixed variables for the internally
appended options, so here is one more conversion to sanitize the
naming convention.

I did not touch Makefiles under tools/ since the tools build system
is a different world.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Palmer Dabbelt <palmer@sifive.com>


# e85d1d65 22-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: test dead code/data elimination support in Kconfig

This config option should be enabled only when both the compiler and
the linker support necessary flags. Add proper dependencies to Kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# dd5806ed 16-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove "rpm" target, which is alias of "rpm-pkg"

As commit ebaad7d36406 ("kbuild: rpm: prompt to use "rpm-pkg" if "rpm"
target is used") noticed, the "rpm" target is now removed.
I assume people have already migrated to "rpm-pkg".

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2e549b2e 16-Aug-2018 Andy Lutomirski <luto@kernel.org>

x86/vdso: Fix vDSO build if a retpoline is emitted

Currently, if the vDSO ends up containing an indirect branch or
call, GCC will emit the "external thunk" style of retpoline, and it
will fail to link.

Fix it by building the vDSO with inline retpoline thunks.

I haven't seen any reports of this triggering on an unpatched
kernel.

Fixes: commit 76b043848fd2 ("x86/retpoline: Add initial retpoline support")
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Matt Rickard <matt@softrans.com.au>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Jason Vas Dias <jason.vas.dias@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.luto@kernel.org


# 2f4df001 06-Aug-2018 Vasily Gorbik <gor@linux.ibm.com>

tracing: Add -mcount-nop option support

-mcount-nop gcc option generates the calls to the profiling functions
as nops which allows to avoid patching mcount jump with NOP instructions
initially.

-mcount-nop gcc option will be activated if platform selects
HAVE_NOP_MCOUNT and gcc actually supports it.
In addition to that CC_USING_NOP_MCOUNT is defined and could be used by
architectures to adapt ftrace patching behavior.

Link: http://lkml.kernel.org/r/patch-3.thread-aa7b8d.git-e02ed2dc082b.your-ad-here.call-01533557518-ext-9465@work.hours

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


# 07d04081 06-Aug-2018 Vasily Gorbik <gor@linux.ibm.com>

tracing: Avoid calling cc-option -mrecord-mcount for every Makefile

Currently if CONFIG_FTRACE_MCOUNT_RECORD is enabled -mrecord-mcount
compiler flag support is tested for every Makefile.

Top 4 cc-option usages:
511 -mrecord-mcount
11 -fno-stack-protector
9 -Wno-override-init
2 -fsched-pressure

To address that move cc-option from scripts/Makefile.build to top Makefile
and export CC_USING_RECORD_MCOUNT to be used in original place.

While doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc
actually supports it).

Link: http://lkml.kernel.org/r/patch-2.thread-aa7b8d.git-de935bace15a.your-ad-here.call-01533557518-ext-9465@work.hours

Acked-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


# f28bc3c3 06-Aug-2018 Vasily Gorbik <gor@linux.ibm.com>

tracing: Handle CC_FLAGS_FTRACE more accurately

CC_FLAGS_FTRACE is exported and later used to remove ftrace relevant
build flags from files which should be built without ftrace support.
For that reason add -mfentry to CC_FLAGS_FTRACE as well. That fixes
a problem with vdso32 build on s390, where -mfentry could not be used
together with -m31 flag.

At the same time flags like -pg and -mfentry are not relevant for asm
files, so avoid adding them to KBUILD_AFLAGS.

Introduce CC_FLAGS_USING instead of CC_USING_FENTRY to collect
-DCC_USING_FENTRY (and future alike) which are relevant for both
KBUILD_CFLAGS and KBUILD_AFLAGS.

Link: http://lkml.kernel.org/r/patch-1.thread-aa7b8d.git-42971afe87de.your-ad-here.call-01533557518-ext-9465@work.hours

Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


# 94710cac 12-Aug-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18


# 3fca1700 07-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: make samples really depend on headers_install

Kernel headers must be installed into $(objtree)/usr/include to avoid
the build failure of samples.

Commit ddea05fa148b ("kbuild: make samples depend on headers_install")
addressed this, but "samples/" is only used for the single target build.

"make samples/" properly installs kernel headers, but it does not work
for general building because a phony target "sample" (no trailing slash)
is used.

Reported-by: David Howells <dhowells@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: David Howells <dhowells@redhat.com>


# 63e31a67 03-Aug-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add %asm-generic to no-dot-config-targets

asm-generic and uapi-asm-generic do not depend on the kernel
configuration. In fact, uapi-asm-generic is the prerequisite of
headers_{install,check}, hence it should not require the .config file.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Richard Weinberger <richard@nod.at>


# 1ffaddd0 05-Aug-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc8


# acb18725 29-Jul-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc7


# 43fee2b2 24-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not redirect the first prerequisite for filechk

Currently, filechk unconditionally opens the first prerequisite and
redirects it as the stdin of a filechk_* rule. Hence, every target
using $(call filechk,...) must list something as the first prerequisite
even if it is unneeded.

'< $<' is actually unneeded in most cases. Each rule can explicitly
adds it if necessary.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2063945f 20-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove auto.conf from prerequisite of phony targets

The top-level Makefile adds include/config/auto.conf as
prerequisites of 'scripts', 'prepare1', etc.

They were needed to terminate the build when include/config/auto.conf
is missing.

Now that the inclusion of include/config/auto.conf is mandatory
in the top-level Makefile if dot-config is 1 (Note 'include' directive
is used instead of '-include').

Make terminates the build by itself if it fails to create or update
include/config/auto.conf so we are sure that include/config/auto.conf
exists in the very first stage of make.

I am still keeping include/config/auto.conf as the prerequisite of
%/modules.builtin because modules.builtin is a real file. According
to commit a6c366324cac ("kbuild: Do not unnecessarily regenerate
modules.builtin"), it is intentional to compare time-stamps between
%/modules.builtin and include/config/auto.conf . I moved tristate.conf
here because it is only included from scripts/Makefile.modbuiltin.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a29d4d8c 20-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not update config for 'make kernelrelease'

'make kernelrelease' depends on CONFIG_LOCALVERSION(_AUTO), but
for the same reason as install targets, we do not want to update
the configuration just for printing the kernelrelease string.

This is likely to happen when you compiled the kernel with
CROSS_COMPILE, but forget to pass it to 'make kernelrelease'.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d7942413 20-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: do not update config when running install targets

"make syncconfig" is automatically invoked when any of the following
happens:

- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed

Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.

Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.

Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.

This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.

Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.

Now, Make targets are categorized into 3 groups:

[1] Do not need the kernel configuration at all

help, coccicheck, headers_install etc.

[2] Need the latest kernel configuration

If new config options are added, Kconfig will show prompt to
ask user's selection.

Build targets such as vmlinux, in-kernel modules are the cases.

[3] Need the kernel configuration, but do not want to update it

Install targets except headers_install, and external modules
are the cases.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0a16d2e8 20-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: use 'include' directive to load auto.conf from top Makefile

When you build targets that require the kernel configuration, dot-config
is set to 1, then the top-level Makefile includes auto.conf. However,
Make considers its inclusion is optional because the '-include' directive
is used here.

If a necessary configuration file is missing for the external module
building, the following error message is displayed:

ERROR: Kernel configuration is invalid.
include/generated/autoconf.h or include/config/auto.conf are missing.
Run 'make oldconfig && make prepare' on kernel src to fix it.

However, Make still continues building; /bin/false let the creation of
'include/config/auto.config' fail, but Make can ignore the error since
it is included by the '-include' directive.

I guess the reason of using '-include' directive was to suppress
the warning when you build the kernel from a pristine source tree:

Makefile:605: include/config/auto.conf: No such file or directory

The previous commit made sure include/config/auto.conf exists after
the 'make *config' stage. Now, we can use the 'include' directive
without showing the warning.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d72e90f3 22-Jul-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc6


# f92d19e0 09-Jul-2018 Laura Abbott <labbott@redhat.com>

kbuild: Use HOST*FLAGS options from the command line

Now that we have the rename in place, reuse the HOST*FLAGS options as
something that can be set from the command line and included with the
rest of the flags.

Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8377bd2b 09-Jul-2018 Laura Abbott <labbott@redhat.com>

kbuild: Rename HOST_LOADLIBES to KBUILD_HOSTLDLIBS

In preparation for enabling command line LDLIBS, re-name HOST_LOADLIBES
to KBUILD_HOSTLDLIBS as the internal use only flags. Also rename
existing usage to HOSTLDLIBS for consistency. This should not have any
visible effects.

Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# b90a3680 09-Jul-2018 Laura Abbott <labbott@redhat.com>

kbuild: Rename HOSTLDFLAGS to KBUILD_HOSTLDFLAGS

In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS
to KBUILD_HOSTLDFLAGS as the internal use only flags. This should not
have any visible effects.

Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 10844aeb 09-Jul-2018 Laura Abbott <labbott@redhat.com>

kbuild: Rename HOSTCXXFLAGS to KBUILD_HOSTCXXFLAGS

In preparation for enabling command line CXXFLAGS, re-name HOSTCXXFLAGS
to KBUILD_HOSTCXXFLAGS as the internal use only flags. This should not
have any visible effects.

Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 96f14fe7 09-Jul-2018 Laura Abbott <labbott@redhat.com>

kbuild: Rename HOSTCFLAGS to KBUILD_HOSTCFLAGS

In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to
KBUILD_HOSTCFLAGS as the internal use only flags. This should not have
any visible effects.

Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9d3cce1e 15-Jul-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc5


# 6d79a7b4 12-Jul-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: suppress warnings from 'getconf LFS_*'

Suppress warnings for systems that do not recognize LFS_*.

getconf: no such configuration parameter `LFS_CFLAGS'
getconf: no such configuration parameter `LFS_LDFLAGS'
getconf: no such configuration parameter `LFS_LIBS'

Fixes: d7f14c66c273 ("kbuild: Enable Large File Support for hostprogs")
Reported-by: Chen Feng <puck.chen@hisilicon.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>


# 1e4b044d 08-Jul-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc4


# bd412d81 04-Jul-2018 Ulf Magnusson <ulfalizer@gmail.com>

kbuild: .PHONY is not a variable, but PHONY is

.PHONY is a target, not a variable.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 021c9179 01-Jul-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc3


# 88e85a7d 25-Jun-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

bpfilter: check compiler capability in Kconfig

With the brand-new syntax extension of Kconfig, we can directly
check the compiler capability in the configuration phase.

If the cc-can-link.sh fails, the BPFILTER_UMH is automatically
hidden by the dependency.

I also deleted 'default n', which is no-op.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


# 7daf201d 24-Jun-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc2


# ce397d21 16-Jun-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.18-rc1


# 050e9baa 13-Jun-2018 Linus Torvalds <torvalds@linux-foundation.org>

Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables

The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.

That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.

HOWEVER.

It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like

CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_STACKPROTECTOR_AUTO=y

and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.

The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one. This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).

This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:

CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.

Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 5aadfdeb 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kcov: test compiler capability in Kconfig and correct dependency

As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
be used with care - it forces a lower limit of another symbol, ignoring
the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
dependency.

Now that Kconfig can test compiler capability, let's handle this in a
more sophisticated way.

There are two ways to enable KCOV; use the compiler that natively
supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
the compiler has ability to build GCC plugins. Hence, the correct
dependency for KCOV is:

depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS

You do not need to build the SANCOV plugin if the compiler already
supports -fsanitize-coverage=trace-pc. Hence, the select should be:

select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC

With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
scripts/Makefile.gcc-plugins can be cleaner.

I also cleaned up Kconfig and scripts/Makefile.kcov as well.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# 2a61f474 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

stack-protector: test compiler capability in Kconfig and drop AUTO mode

Move the test for -fstack-protector(-strong) option to Kconfig.

If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.

I also turned the 'choice' into only two boolean symbols. The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.

X86 has additional shell scripts in case the compiler supports those
options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Kees Cook <keescook@chromium.org>


# 315bab4e 07-Jun-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE

Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.

The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.

However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.

$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig

Things are happening like this:

Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.

To create or update auto.conf, the following line is triggered:

include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig

This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.

The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.

To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.

For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.

include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.

Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>


# 819dd92b 04-Jun-2018 Alexei Starovoitov <ast@kernel.org>

bpfilter: switch to CC from HOSTCC

check that CC can build executables and use that compiler instead of HOSTCC

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>


# 29dcea88 03-Jun-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17


# 1f2f01b1 30-May-2018 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: add machine size to CHECKFLAGS

By default, sparse assumes a 64bit machine when compiled on x86-64
and 32bit when compiled on anything else.

This can of course create all sort of problems for the other archs, like
issuing false warnings ('shift too big (32) for type unsigned long'), or
worse, failing to emit legitimate warnings.

Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 14516765 28-May-2018 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: add endianness flag to CHEKCFLAGS

The kernel depends on macros like __BYTE_ORDER__,
__BIG_ENDIAN__ or __LITTLE_ENDIAN__.

OTOH, sparse doesn't know about the endianness of the kernel and
by default uses the same as the machine on which sparse was built.

Ensure that sparse can predefine the macros corresponding to
how the kernel was configured by adding -m{big,little}-endian
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the equivalent done in arch specific Makefiles.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 59f7b584 28-May-2018 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: $(CHECK) doesnt need NOSTDINC_FLAGS twice

Currently, $(CHECK) receives NOSTDINC_FLAGS twice:
* first directly in the main Makefile via CHECKFLAGS,
* then indirectly in scripts/Makefile.build via c_flags.

Since once is enough, leave the occurence via c_flags and
remove the one via CHECKFLAGS.

Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 21c54b77 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kconfig: show compiler version text in the top comment

The kernel configuration phase is now tightly coupled with the compiler
in use. It will be nice to show the compiler information in Kconfig.

The compiler information will be displayed like this:

$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- config
scripts/kconfig/conf --oldaskconfig Kconfig
*
* Linux/arm64 4.16.0-rc1 Kernel Configuration
*
*
* Compiler: aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
*
*
* General setup
*
Compile also drivers which will not load (COMPILE_TEST) [N/y/?]

If you use GUI methods such as menuconfig, it will be displayed in the
top menu.

This is simply implemented by using the 'comment' statement. So, it
will be saved into the .config file as well.

This commit has a very important meaning. If the compiler is upgraded,
Kconfig must be re-run since different compilers have different sets
of supported options.

All referenced environments are written to include/config/auto.conf.cmd
so that any environment change triggers syncconfig, and prompt the user
to input new values if needed.

With this commit, something like follows will be added to
include/config/auto.conf.cmd

ifneq "$(CC_VERSION_TEXT)" "aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011"
include/config/auto.conf: FORCE
endif

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# 2972666a 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kconfig: replace $(UNAME_RELEASE) with function call

Now that 'shell' function is supported, this can be self-contained in
Kconfig.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>


# 104daea1 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kconfig: reference environment variables directly and remove 'option env='

To get access to environment variables, Kconfig needs to define a
symbol using "option env=" syntax. It is tedious to add a symbol entry
for each environment variable given that we need to define much more
such as 'CC', 'AS', 'srctree' etc. to evaluate the compiler capability
in Kconfig.

Adding '$' for symbol references is grammatically inconsistent.
Looking at the code, the symbols prefixed with 'S' are expanded by:
- conf_expand_value()
This is used to expand 'arch/$ARCH/defconfig' and 'defconfig_list'
- sym_expand_string_value()
This is used to expand strings in 'source' and 'mainmenu'

All of them are fixed values independent of user configuration. So,
they can be changed into the direct expansion instead of symbols.

This change makes the code much cleaner. The bounce symbols 'SRCARCH',
'ARCH', 'SUBARCH', 'KERNELVERSION' are gone.

sym_init() hard-coding 'UNAME_RELEASE' is also gone. 'UNAME_RELEASE'
should be replaced with an environment variable.

ARCH_DEFCONFIG is a normal symbol, so it should be simply referenced
without '$' prefix.

The new syntax is addicted by Make. The variable reference needs
parentheses, like $(FOO), but you can omit them for single-letter
variables, like $F. Yet, in Makefiles, people tend to use the
parenthetical form for consistency / clarification.

At this moment, only the environment variable is supported, but I will
extend the concept of 'variable' later on.

The variables are expanded in the lexer so we can simplify the token
handling on the parser side.

For example, the following code works.

[Example code]

config MY_TOOLCHAIN_LIST
string
default "My tools: CC=$(CC), AS=$(AS), CPP=$(CPP)"

[Result]

$ make -s alldefconfig && tail -n 1 .config
CONFIG_MY_TOOLCHAIN_LIST="My tools: CC=gcc, AS=as, CPP=gcc -E"

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# f1089c92 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove CONFIG_CROSS_COMPILE support

Kbuild provides a couple of ways to specify CROSS_COMPILE:

[1] Command line
[2] Environment
[3] arch/*/Makefile (only some architectures)
[4] CONFIG_CROSS_COMPILE

[4] is problematic for the compiler capability tests in Kconfig.
CONFIG_CROSS_COMPILE allows users to change the compiler prefix from
'make menuconfig', etc. It means, the compiler options would have
to be all re-calculated everytime CONFIG_CROSS_COMPILE is changed.

To avoid complexity and performance issues, I'd like to evaluate
the shell commands statically, i.e. only parsing Kconfig files.

I guess the majority is [1] or [2]. Currently, there are only
5 defconfig files that specify CONFIG_CROSS_COMPILE.
arch/arm/configs/lpc18xx_defconfig
arch/hexagon/configs/comet_defconfig
arch/nds32/configs/defconfig
arch/openrisc/configs/or1ksim_defconfig
arch/openrisc/configs/simple_smp_defconfig

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# e08d6de4 28-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove kbuild cache

The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).

However, this turned out not so clever as I had first expected.
Actually, it is problematic. For example, "$(CC) -print-file-name"
is cached. If the compiler is updated, the stale search path causes
build error, which is difficult to figure out. Another problem
scenario is cache files could be touched while install targets are
running under the root permission. We can patch them if desired,
but the build infrastructure is getting uglier and uglier.

Now, we are going to move compiler flag tests to the configuration
phase. If this is completed, the result of compiler tests will be
naturally cached in the .config file. We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.

To start this work with a cleaner code base, remove the kbuild
cache first.

Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>


# b04e2177 27-May-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc7


# 771c577c 20-May-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc6


# 6ca8d943 09-May-2018 Nicholas Piggin <npiggin@gmail.com>

kbuild: LD_DEAD_CODE_DATA_ELIMINATION no -ffunction-sections/-fdata-sections for module build

Modules do not tend to cope with -ffunction-sections, even though they
do not link with -gc-sections. It may be possible for unused symbols to
be trimmed from modules, but in general that would take much more work
in architecture module linker scripts.

For now, enable these only for kernel build.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 5a144a1a 09-May-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

depmod.sh: remove symbol prefix support

CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX was selected by BLACKFIN, METAG.
They were removed by commit 4ba66a976072 ("arch: remove blackfin port"),
commit bb6fb6dfcc17 ("metag: Remove arch/metag/"), respectively.

No more architecture enables CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX,
hence the last argument of scripts/depmod.sh can be removed.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>


# 8438ee76 15-May-2018 Michal Kubecek <mkubecek@suse.cz>

Makefile: disable PIE before testing asm goto

Since commit e501ce957a78 ("x86: Force asm-goto"), aarch64 build on
distributions which enable PIE by default (e.g. openSUSE Tumbleweed) does
not detect support for asm goto correctly. The problem is that ARM specific
part of scripts/gcc-goto.sh fails with PIE even with recent gcc versions.
Moving the asm goto detection up in Makefile put it before the place where
we disable PIE. As a result, kernel is built without jump label support.

Move the lines disabling PIE before the asm goto test to make it work.

Fixes: e501ce957a78 ("x86: Force asm-goto")
Reported-by: Andreas Faerber <afaerber@suse.com>
Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# c64ba044 26-Apr-2018 Nick Desaulniers <ndesaulniers@google.com>

kbuild: gcov: enable -fno-tree-loop-im if supported

Clang does not recognize this compiler option.

Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 67b8d5c7 13-May-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc5


# 75bc37fe 06-May-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc4


# 6da6c0db 29-Apr-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux v4.17-rc3


# 6d08b06e 22-Apr-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc2


# 60cc43fc 15-Apr-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.17-rc1


# a73619a8 29-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: use -fmacro-prefix-map to make __FILE__ a relative path

The __FILE__ macro is used everywhere in the kernel to locate the file
printing the log message, such as WARN_ON(), etc. If the kernel is
built out of tree, this can be a long absolute path, like this:

WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:...

This is because Kbuild runs in the objtree instead of the srctree,
then __FILE__ is expanded to a file path prefixed with $(srctree)/.

Commit 9da0763bdd82 ("kbuild: Use relative path when building in a
subdir of the source tree") improved this to some extent; $(srctree)
becomes ".." if the objtree is a child of the srctree.

For other cases of out-of-tree build, __FILE__ is still the absolute
path. It also means the kernel image depends on where it was built.

A brand-new option from GCC, -fmacro-prefix-map, solves this problem.
If your compiler supports it, __FILE__ is the relative path from the
srctree regardless of O= option. This provides more readable log and
more reproducible builds.

Please note __FILE__ is always an absolute path for external modules.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4fa8bc94 23-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: rename *-asn1.[ch] to *.asn1.[ch]

Our convention is to distinguish file types by suffixes with a period
as a separator.

*-asn1.[ch] is a different pattern from other generated sources such
as *.lex.c, *.tab.[ch], *.dtb.S, etc. More confusing, files with
'-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in
files:
net/netfilter/nf_conntrack_h323_asn1.c
include/linux/netfilter/nf_conntrack_h323_asn1.h
include/linux/sunrpc/gss_asn1.h

Rename generated files to *.asn1.[ch] for consistency.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 3ca3273e 23-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clean up *-asn1.[ch] patterns from top-level Makefile

Clean up these patterns from the top Makefile to omit 'clean-files'
in each Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9a8dfb39 23-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clean up *.lex.c and *.tab.[ch] patterns from top-level Makefile

Files suffixed by .lex.c, .tab.[ch] are generated lexers, parsers,
respectively. Clean them up globally from the top Makefile.

Some of the final host programs those lexer/parser are linked into
are necessary for building external modules, but the intermediates
are unneeded. They can be cleaned away by 'make clean' instead of
'make mrproper'.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Frank Rowand <frowand.list@gmail.com>


# 0adb3285 01-Apr-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16


# 3eb2ce82 25-Mar-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc7


# e9781b52 13-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add PYTHON2 and PYTHON3 variables

The variable 'PYTHON' allows users to specify a proper executable
name in case the default 'python' does not work. However, this does
not address the case where both Python 2.x and 3.x scripts are used
in one source tree.

PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a
convention for Python scripts portability. Here is a quotation:

In order to tolerate differences across platforms, all new code
that needs to invoke the Python interpreter should not specify
'python', but rather should specify either 'python2' or 'python3'.
This distinction should be made in shebangs, when invoking from a
shell script, when invoking via the system() call, or when invoking
in any other context.
One exception to this is scripts that are deliberately written to
be source compatible with both Python 2.x and 3.x. Such scripts may
continue to use python on their shebang line without affecting their
portability.

To meet this requirement, this commit adds new variables 'PYTHON2'
and 'PYTHON3'.

arch/ia64/scripts/unwcheck.py is the only script that has ever used
$(PYTHON). Recent commit bd5edbe67794 ("ia64: convert unwcheck.py to
python3") converted it to be compatible with both Python 2.x and 3.x,
so this is the exceptional case where the use of 'python' is allowed.
So, I did not touch arch/ia64/Makefile.

tools/perf/Makefile.config sets PYTHON and PYTHON2 by itself, so it
is not affected by this commit.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 911a91c3 28-Feb-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kconfig: rename silentoldconfig to syncconfig

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
historical misnomer. That commit removed it from help and docs since
it is an internal interface. If so, it should be allowed to rename
it to something more intuitive. 'syncconfig' is the one I came up
with because it updates the .config if necessary, then synchronize
include/generated/autoconf.h and include/config/* with it.

You should not manually invoke 'silentoldcofig'. Display warning if
used in case existing scripts are doing wrong.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>


# 3fdc7d3f 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS

If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from
a pristine state, the vmlinux is linked twice.

[1] A user runs 'make'

[2] First build with empty autoksyms.h

[3] adjust_autoksyms.sh updates autoksyms.h and recurses 'make vmlinux'

--------(begin sub-make)--------
[4] Second build with new autoksyms.h

[5] link-vmlinux.sh is invoked because vmlinux is missing
---------(end sub-make)---------

[6] link-vmlinux.sh is invoked again despite vmlinux is up-to-date.

The reason of [6] is probably because Make already decided to update
vmlinux at the time of [2] because vmlinux was missing when Make
built up the dependency graph.

Because if_changed is implemented based on $?, this issue can be
narrowed down to how Make handles $?.

You can test it with the following simple code:

[Test Makefile]
A: B
@echo newer prerequisite: $?
cp B A

B: C
cp C B
touch A

[Result]
$ rm -f A B
$ touch C
$ make
cp C B
touch A
newer prerequisite: B
cp B A

Here, 'A' has been touched in the recipe of 'B'. So, the dependency
'A: B' has already been met before the recipe of 'A' is executed.
However, Make does not notice the fact that the recipe of 'B' also
updates 'A' as a side-effect.

The situation is similar in this case; the vmlinux has actually been
updated in the vmlinux_prereq target. Make cannot predict this, so
judges the vmlinux is old.

link-vmlinux.sh is costly, so it is better to not run it when unneeded.
Split CONFIG_TRIM_UNUSED_KSYMS recursion to a dedicated target.

The reason of commit 2441e78b1919 ("kbuild: better abstract vmlinux
sequential prerequisites") was to cater to CONFIG_BUILD_DOCSRC, but
it was later removed by commit 184892925118 ("samples: move blackfin
gptimers-example from Documentation").

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>


# fbfa9be9 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move include/config/ksym/* to include/ksym/*

The idea of using fixdep was inspired by Kconfig, but autoksyms
belongs to a different group. So, I want to move those touched
files under include/config/ksym/ to include/ksym/.

The directory include/ksym/ can be removed by 'make clean' because
it is meaningless for the external module building.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>


# 1f50b80a 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move CONFIG_TRIM_UNUSED_KSYMS code unneeded for external module

The external module building does not need to parse this code because
KBUILD_MODULES is always set anyway.

Move this code inside the "ifeq ($(KBUILD_EXTMOD),) ... endif" block.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>


# 07a422bb 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: restore autoksyms.h touch to the top Makefile

Commit d3fc425e819b ("kbuild: make sure autoksyms.h exists early")
moved the code that touches autoksyms.h to scripts/kconfig/Makefile
with obscure reason.

From Nicolas' comment [1], he did not seem to be sure about the root
cause.

I guess I figured it out, so here is a fix-up I think is more correct.
According to the error log in the original post [2], the build failed
in scripts/mod/devicetable-offsets.c

scripts/mod/Makefile is descended from scripts/Makefile, which is
invoked from the top-level Makefile by the 'scripts' target.

To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs).
This depends on 'prepare' and 'scripts' as follows:

$(vmlinux-dirs): prepare scripts

Because there is no dependency between 'prepare' and 'scripts', the
parallel building can execute them simultaneously.

'prepare' depends on 'prepare1', which touched autoksyms.h, while
'scripts' descends into script/, then scripts/mod/, which needs
<generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS. It was the
reason of the race.

I am not happy to have unrelated code in the Kconfig Makefile, so
getting it back to the top Makefile.

I removed the standalone test target because I want to use it to
create an empty autoksyms.h file. Here is a little improvement;
unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS
is disabled.

[1] https://lkml.org/lkml/2016/11/30/734
[2] https://lkml.org/lkml/2016/11/30/531

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>


# d8821622 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move 'scripts' target below

Just a trivial change to prepare for the next commit.
This target is still invisible from external module building.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ce99d0bf 16-Mar-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clear LDFLAGS in the top Makefile

Currently LDFLAGS is not cleared, so same flags are accumulated in
LDFLAGS when the top Makefile is recursively invoked.

I found unneeded rebuild for ARCH=arm64 when CONFIG_TRIM_UNUSED_KSYMS
is enabled. If include/generated/autoksyms.h is updated, the top
Makefile is recursively invoked, then arch/arm64/Makefile adds one
more '-maarch64linux'. Due to the command line change, modules are
rebuilt needlessly.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>


# 22340a06 11-Feb-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: process mixture of clean/build targets one by one

Support parallel building of clean, config, and build targets in a
single command.

For example,

make -j<N> clean all

or

make -j<N> mrproper defconfig all

They should be handled one by one.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f49821ee 10-Feb-2018 Nicholas Piggin <npiggin@gmail.com>

kbuild: rename built-in.o to built-in.a

Incremental linking is gone, so rename built-in.o to built-in.a, which
is the usual extension for archive files.

This patch does two things, first is a simple search/replace:

git grep -l 'built-in\.o' | xargs sed -i 's/built-in\.o/built-in\.a/g'

The second is to invert nesting of nested text manipulations to avoid
filtering built-in.a out from libs-y2:

-libs-y2 := $(filter-out %.a, $(patsubst %/, %/built-in.a, $(libs-y)))
+libs-y2 := $(patsubst %/, %/built-in.a, $(filter-out %.a, $(libs-y)))

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0f0e8de3 19-Mar-2018 Stefan Agner <stefan@agner.ch>

kbuild: set no-integrated-as before incl. arch Makefile

In order to make sure compiler flag detection for ARM works
correctly the no-integrated-as flags need to be set before
including the arch specific Makefile.

Fixes: cfe17c9bbe6a ("kbuild: move cc-option and cc-disable-warning after incl. arch Makefile")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 87e0d4f0 20-Mar-2018 Daniel Borkmann <daniel@iogearbox.net>

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>


# e501ce95 17-Jan-2018 Peter Zijlstra <peterz@infradead.org>

x86: Force asm-goto

We want to start using asm-goto to guarantee the absence of dynamic
branches (and thus speculation).

A primary prerequisite for this is of course that the compiler
supports asm-goto. This effecively lifts the minimum GCC version to
build an x86 kernel to gcc-4.5.

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: torvalds@linux-foundation.org
Link: https://lkml.kernel.org/r/20180319201327.GJ4043@hirez.programming.kicks-ass.net


# c698ca52 18-Mar-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc6


# bb9d8126 09-Mar-2018 Arnd Bergmann <arnd@arndb.de>

arch: remove tile port

The Tile architecture port was added by Chris Metcalf in 2010, and
maintained until early 2018 when he orphaned it due to his departure
from Mellanox, and nobody else stepped up to maintain it. The product
line is still around in the form of the BlueField SoC, but no longer
uses the Tile architecture.

There are also still products for sale with Tile-GX SoCs, notably the
Mikrotik CCR router family. The products all use old (linux-3.3) kernels
with lots of patches and won't be upgraded by their manufacturers. There
have been efforts to port both OpenWRT and Debian to these, but both
projects have stalled and are very unlikely to be continued in the future.

Given that we are reasonably sure that nobody is still using the port
with an upstream kernel any more, it seems better to remove it now while
the port is in a good shape than to let it bitrot for a few years first.

Cc: Chris Metcalf <chris.d.metcalf@gmail.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: http://www.mellanox.com/page/npu_multicore_overview
Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>


# 0c8efd61 11-Mar-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc5


# 661e50bc 04-Mar-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc4


# 0da4fabd 22-Feb-2018 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: test --build-id linker flag by ld-option instead of cc-ldoption

'--build-id' is passed to $(LD), so it should be tested by 'ld-option'.

This seems a kind of misconversion when ld-option was renamed to
cc-ldoption.

Commit f86fd3066052 ("kbuild: rename ld-option to cc-ldoption") renamed
all instances of 'ld-option' to 'cc-ldoption'.

Then, commit 691ef3e7fdc1 ("kbuild: introduce ld-option") re-added
'ld-option' as a new implementation.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6c49f359 15-Feb-2018 Luc Van Oostenryck <luc.vanoostenryck@gmail.com>

kbuild: disable sparse warnings about unknown attributes

Currently, sparse issues warnings on code using an attribute
it doesn't know about.

One of the problem with this is that these warnings have no
value for the developer, it's just noise for him. At best these
warnings tell something about some deficiencies of sparse itself
but not about a potential problem with code analyzed.

A second problem with this is that sparse release are, alas,
less frequent than new attributes are added to GCC.

So, avoid the noise by asking sparse to not warn about
attributes it doesn't know about.

Reference: https://marc.info/?l=linux-sparse&m=151871600016790
Reference: https://marc.info/?l=linux-sparse&m=151871725417322
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 61277981 13-Feb-2018 Ulf Magnusson <ulfalizer@gmail.com>

Makefile: Fix lying comment re. silentoldconfig

The comment above the silentoldconfig invocation is outdated.
'make oldconfig' updates just .config and doesn't touch the
include/config/ tree.

This came up in https://lkml.org/lkml/2018/2/12/415.

While fixing the comment, make it more informative by explaining the
purpose of the unfortunately named silentoldconfig.

I can't make sense of the comment re. auto.conf.cmd and a cleaned tree.
include/config/auto.conf and include/config/auto.conf.cmd are both
created simultaneously by silentoldconfig (in
scripts/kconfig/confdata.c, by conf_write_autoconf()), and nothing seems
to remove auto.conf.cmd that wouldn't remove auto.conf. Remove that part
of the comment rather than blindly copying it. It might be a leftover
from an older way of doing things.

The include/config/auto.conf.cmd prerequisite might be there to ensure
that silentoldconfig gets rerun if conf_write_autoconf() fails between
writing out auto.conf.cmd and auto.conf (a comment in the function
indicates that auto.conf is deliberately written out last to mark
completion of the operation). It seems the Makefile dependency between
include/config/auto.conf and .config would already take care of that
though, since include/config/auto.conf would still be out of date re.
.config if the operation fails.

Cop out and leave the prerequisite in for now.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4a3928c6 25-Feb-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc3


# d5028ba8 06-Feb-2018 Peter Zijlstra <peterz@infradead.org>

objtool, retpolines: Integrate objtool with retpoline support more closely

Disable retpoline validation in objtool if your compiler sucks, and otherwise
select the validation stuff for CONFIG_RETPOLINE=y (most builds would already
have it set due to ORC).

Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 91ab883e 18-Feb-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc2


# 7928b2cb 11-Feb-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.16-rc1


# 44c6dc94 06-Feb-2018 Kees Cook <keescook@chromium.org>

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>


# 2bc2f688 06-Feb-2018 Kees Cook <keescook@chromium.org>

Makefile: move stack-protector availability out of Kconfig

Various portions of the kernel, especially per-architecture pieces,
need to know if the compiler is building with the stack protector.
This was done in the arch/Kconfig with 'select', but this doesn't
allow a way to do auto-detected compiler support. In preparation for
creating an on-if-available default, move the logic for the definition of
CONFIG_CC_STACKPROTECTOR into the Makefile.

Link: http://lkml.kernel.org/r/1510076320-69931-3-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>


# 2b838392 06-Feb-2018 Kees Cook <keescook@chromium.org>

Makefile: move stack-protector compiler breakage test earlier

In order to make stack-protector failures warn instead of unconditionally
breaking the build, this moves the compiler output sanity-check earlier,
and sets a flag for later testing. Future patches can choose to warn or
fail, depending on the flag value.

Link: http://lkml.kernel.org/r/1510076320-69931-2-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>


# 0e410e15 06-Feb-2018 Andrey Konovalov <andreyknvl@google.com>

kasan: don't emit builtin calls when sanitization is off

With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.

The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.

The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.

Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.1516384594.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 0a5f4176 06-Feb-2018 Sodagudi Prasad <psodagud@codeaurora.org>

kbuild: clang: disable unused variable warnings only when constant

Currently, GCC disables -Wunused-const-variable, but not
-Wunused-variable, so warns unused variables if they are
non-constant.

While, Clang does not warn unused variables at all regardless of
the const qualifier because -Wno-unused-const-variable is implied
by the stronger option -Wno-unused-variable.

Disable -Wunused-const-variable instead of -Wunused-variable so that
GCC and Clang work in the same way.

Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d8a5b805 28-Jan-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15


# 0c5b9b5d 21-Jan-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc9


# a8750ddc 14-Jan-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc8


# b2cd1df6 07-Jan-2018 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc7


# 30a7acd5 31-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc6


# 3ce120b1 29-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

kbuild: add '-fno-stack-check' to kernel build options

It appears that hardened gentoo enables "-fstack-check" by default for
gcc.

That doesn't work _at_all_ for the kernel, because the kernel stack
doesn't act like a user stack at all: it's much smaller, and it doesn't
auto-expand on use. So the extra "probe one page below the stack" code
generated by -fstack-check just breaks the kernel in horrible ways,
causing infinite double faults etc.

[ I have to say, that the particular code gcc generates looks very
stupid even for user space where it works, but that's a separate
issue. ]

Reported-and-tested-by: Alexander Tsoy <alexander@tsoy.me>
Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Cc: stable@kernel.org
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 464e1d5f 23-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc5


# 1291a0d5 17-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc4


# 73a4f6db 09-Dec-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: add LEX and YACC variables

Allow users to use their favorite lexer / parser generators.
This is useful for me to test various flex and bison versions.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 50c4c4e2 10-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc3


# cfe17c9b 27-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move cc-option and cc-disable-warning after incl. arch Makefile

Geert reported commit ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before
incl. arch Makefile") broke cross-compilation using a cross-compiler
that supports less compiler options than the host compiler.

For example,

cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"

This problem happens on architectures that setup CROSS_COMPILE in their
arch/*/Makefile.

Move the cc-option and cc-disable-warning back to the original position,
but keep the Clang target options untouched.

Fixes: ae6b289a3789 ("kbuild: Set KBUILD_CFLAGS before incl. arch Makefile")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>


# ae64f9bd 03-Dec-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc2


# 4fbd8d19 26-Nov-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.15-rc1


# ef46d9b3 16-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clean up *.i and *.lst patterns by make clean

*.i and *.lst are supported by the single target build. Clean up them.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ebaad7d3 15-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: rpm: prompt to use "rpm-pkg" if "rpm" target is used

The "rpm" has been kept for backward compatibility since pre-git era.
I am planning to remove it after the Linux 4.18 release. Annouce the
end of the support, prompting to use "rpm-pkg" instead.

If you use "rpm", it will work like "rpm-pkg", but warning messages
will be displayed as follows:

WARNING: "rpm" target will be removed after Linux 4.18
Please use "rpm-pkg" instead.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ae6b289a 07-Nov-2017 Chris Fries <cfries@google.com>

kbuild: Set KBUILD_CFLAGS before incl. arch Makefile

Set the clang KBUILD_CFLAGS up before including arch/ Makefiles,
so that ld-options (etc.) can work correctly.

This fixes errors with clang such as ld-options trying to CC
against your host architecture, but LD trying to link against
your target architecture.

Signed-off-by: Chris Fries <cfries@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f7adc312 07-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: create built-in.o automatically if parent directory wants it

"obj-y += foo/" syntax requires Kbuild to visit the "foo" subdirectory
and link built-in.o from that directory. This means foo/Makefile is
responsible for creating built-in.o even if there is no object to
link (in this case, built-in.o is an empty archive).

We have had several fixups like commit 4b024242e8a4 ("kbuild: Fix
linking error built-in.o no such file or directory"), then ended up
with a complex condition as follows:

ifneq ($(strip $(obj-y) $(obj-m) $(obj-) $(subdir-m) $(lib-target)),)
builtin-target := $(obj)/built-in.o
endif

We still have more cases not covered by the above, so we need to add
obj- := dummy.o
in several places just for creating empty built-in.o.

A key point is, the parent Makefile knows whether built-in.o is needed
or not. If a subdirectory needs to create built-in.o, its parent can
tell the fact when descending.

If non-empty $(need-builtin) flag is passed from the parent, built-in.o
should be created. $(obj-y) should be still checked to support the
single target "%/". All of ugly tricks will go away.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>


# 16f8259c 05-Nov-2017 Bjørn Forsman <bjorn.forsman@gmail.com>

kbuild: /bin/pwd -> pwd

Most places use pwd and rely on $PATH lookup. Moving the remaining
absolute path /bin/pwd users over for consistency.

Also, a reason for doing /bin/pwd -> pwd instead of the other way around
is because I believe build systems should make little assumptions on
host filesystem layout. Case in point, we do this kind of patching
already in NixOS.

Ref. commit 028568d84da3cfca49f5f846eeeef01441d70451
("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)").

Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# d677a4d6 17-Nov-2017 Victor Chibotaru <tchibo@google.com>

Makefile: support flag -fsanitizer-coverage=trace-cmp

The flag enables Clang instrumentation of comparison operations
(currently not supported by GCC). This instrumentation is needed by the
new KCOV device to collect comparison operands.

Link: http://lkml.kernel.org/r/20171011095459.70721-2-glider@google.com
Signed-off-by: Victor Chibotaru <tchibo@google.com>
Signed-off-by: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Popov <alex.popov@linux.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: <syzkaller@googlegroups.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 7f855fc8 14-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move coccicheck help from scripts/Makefile.help to top Makefile

In my view, it is not helpful to have a separate file just for
the coccicheck help message. Merge scripts/Makefile.help into
the top-level Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>


# 2982c953 13-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove redundant $(wildcard ...) for cmd_files calculation

I do not see any reason why $(wildcard ...) needs to be called twice
for computing cmd_files. Remove the first one.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 433dc2eb 12-Oct-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

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>


# 4e562071 16-Oct-2017 Douglas Anderson <dianders@chromium.org>

kbuild: Cache a few more calls to the compiler

These are a few stragglers that I left out of the original patch to
cache calls to the C compiler ("kbuild: Add a cache for generated
variables") because they bleed out into the main Makefile and thus
uglify things a little bit. The idea is the same here, though.

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>


# 3298b690 16-Oct-2017 Douglas Anderson <dianders@chromium.org>

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>


# bebc6082 12-Nov-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14


# 74ce1896 01-Nov-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: clean up *.dtb and *.dtb.S patterns from top-level Makefile

We need to add "clean-files" in Makfiles to clean up DT blobs, but we
often miss to do so.

Since there are no source files that end with .dtb or .dtb.S, so we
can clean-up those files from the top-level Makefile.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rob Herring <robh@kernel.org>


# 39dae59d 05-Nov-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc8


# b2441318 01-Nov-2017 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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>


# 0b07194b 29-Oct-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc7


# df16aaac 07-Oct-2017 Nick Desaulniers <nick.desaulniers@gmail.com>

kbuild: clang: remove crufty HOSTCFLAGS

When compiling with `make CC=clang HOSTCC=clang`, I was seeing warnings
that clang did not recognize -fno-delete-null-pointer-checks for HOSTCC
targets. These were added in commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").

Clang does not support -fno-delete-null-pointer-checks, so adding it to
HOSTCFLAGS if HOSTCC is clang does not make sense.

It's not clear why the other warnings were disabled, and just for
HOSTCFLAGS, but I can remove them, add -Werror to HOSTCFLAGS and compile
with clang just fine.

Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# bb3f38c3 20-Oct-2017 David Lin <dtwlin@google.com>

kbuild: clang: fix build failures with sparse check

We should avoid using the space character when passing arguments to
clang, because static code analysis check tool such as sparse may
misinterpret the arguments followed by spaces as build targets hence
cause the build to fail.

Signed-off-by: David Lin <dtwlin@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# bb176f67 23-Oct-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc6


# 33d930e5 15-Oct-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc5


# 11af8474 13-Oct-2017 Josh Poimboeuf <jpoimboe@redhat.com>

x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'

Rename the unwinder config options from:

CONFIG_ORC_UNWINDER
CONFIG_FRAME_POINTER_UNWINDER
CONFIG_GUESS_UNWINDER

to:

CONFIG_UNWINDER_ORC
CONFIG_UNWINDER_FRAME_POINTER
CONFIG_UNWINDER_GUESS

... in order to give them a more logical config namespace.

Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# e8939222 09-Oct-2017 Jani Nikula <jani.nikula@intel.com>

Documentation: add script and build target to check for broken file references

Add a simple script and build target to do a treewide grep for
references to files under Documentation, and report the non-existing
file in stderr. It tries to take into account punctuation not part of
the filename, and wildcards, but there are bound to be false positives
too. Mostly seems accurate though.

We've moved files around enough to make having this worthwhile.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 8d73c512 02-Oct-2017 Shuah Khan <shuah@kernel.org>

Makefile: enable dochelp run from main make level

Change to enable dochelp run from main make level to make it easier to
use it.

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 2c1f4f12 03-Oct-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: re-order the code to not parse unnecessary variables

The top Makefile is divided into some sections such as mixed targets,
config targets, build targets, etc.

When we build mixed targets, Kbuild just invokes submake to process
them one by one. In this case, compiler-related variables like CC,
KBUILD_CFLAGS, etc. are unneeded.

Check what kind of targets we are building first, and parse variables
for building only when necessary.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# ba634ece 03-Oct-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: move "_all" target out of $(KBUILD_SRC) conditional

The first "_all" occurrence around line 120 is only visible when
KBUILD_SRC is unset.

If O=... is specified, the working directory is relocated, then the
only second occurrence around line 193 is visible, that is not set
to PHONY.

Move the first one to an always visible place. This clarifies "_all"
is our default target and it is always set to PHONY.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>


# 9d022c54 03-Oct-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: replace $(hdr-arch) with $(SRCARCH)

Since commit 5e53879008b9 ("sparc,sparc64: unify Makefile"), hdr-arch
and SRCARCH always match.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>


# 278ae604 21-Sep-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: link-vmlinux.sh: simplify .version increment

Since commit 1f2bfbd00e46 ("kbuild: link of vmlinux moved to a
script"), it is easy to increment .version without using a temporary
file .old_version.

I do not see anybody who creates the .tmp_version. Probably it is a
left-over of commit 4e25d8bb9550fb ("[PATCH] kbuild: adjust .version
updating"). Just remove it.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8a5776a5 08-Oct-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc4


# bbfe63b6 06-Oct-2017 Randy Dunlap <rdunlap@infradead.org>

Makefile: kselftest: fix grammar typo

Correct typo in kselftest help text.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 028568d8 02-Oct-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)

I thought commit 8e9b46679923 ("kbuild: use $(abspath ...) instead of
$(shell cd ... && /bin/pwd)") was a safe conversion, but it changed
the behavior.

$(abspath ...) / $(realpath ...) does not expand shell special
characters, such as '~'.

Here is a simple Makefile example:

---------------->8----------------
$(info /bin/pwd: $(shell cd ~/; /bin/pwd))
$(info abspath: $(abspath ~/))
$(info realpath: $(realpath ~/))
all:
@:
---------------->8----------------

$ make
/bin/pwd: /home/masahiro
abspath: /home/masahiro/workspace/~
realpath:

This can be a real problem if 'make O=~/foo' is invoked from another
Makefile or primitive shell like dash.

This commit partially reverts 8e9b46679923.

Fixes: 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)")
Reported-by: Julien Grall <julien.grall@arm.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Julien Grall <julien.grall@arm.com>


# 3dd40cb3 03-Oct-2017 Josh Poimboeuf <jpoimboe@redhat.com>

objtool: Upgrade libelf-devel warning to error for CONFIG_ORC_UNWINDER

With CONFIG_ORC_UNWINDER, if the user doesn't have libelf-devel
installed, and they don't see the make warning, their ORC unwinder will
be silently broken. Upgrade the warning to an error.

Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/d9dfc39fb8240998820f9efb233d283a1ee96084.1507079417.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# 9e66317d 01-Oct-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc3


# fbe934d6 10-Jul-2017 Palmer Dabbelt <palmer@dabbelt.com>

RISC-V: Build Infrastructure

This patch contains all the build infrastructure that actually enables
the RISC-V port. This includes Makefiles, linker scripts, and Kconfig
files. It also contains the only top-level change, which adds RISC-V to
the list of architectures that need a sed run to produce the ARCH
variable when building locally.

Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>


# e19b205b 24-Sep-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc2


# 2bc84526 06-Sep-2017 Shuah Khan <shuah@kernel.org>

Makefile: kselftest and kselftest-clean fail for make O=dir case

kselftest and kselftest-clean targets fail when object directory is
specified to relocate objects. Fix it so it can find the source tree
to build from.

make O=/tmp/kselftest_top kselftest

make[1]: Entering directory '/tmp/kselftest_top'
make[2]: Entering directory '/tmp/kselftest_top'
make[2]: *** tools/testing/selftests: No such file or directory. Stop.
make[2]: Leaving directory '/tmp/kselftest_top'
./linux-kselftest/Makefile:1185: recipe for target
'kselftest' failed
make[1]: *** [kselftest] Error 2
make[1]: Leaving directory '/tmp/kselftest_top'
Makefile:145: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 2bd6bf03 16-Sep-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.14-rc1


# df85b2d7 16-Sep-2017 Markus Trippelsdorf <markus@trippelsdorf.de>

firmware: Restore support for built-in firmware

Commit 5620a0d1aac ("firmware: delete in-kernel firmware") removed the
entire firmware directory. Unfortunately it thereby also removed the
support for built-in firmware.

This restores the ability to build firmware directly into the kernel by
pruning the original Makefile to the necessary minimum. The default for
EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/.

Fixes: 5620a0d1aac ("firmware: delete in-kernel firmware")
Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Acked-by: Greg K-H <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 5620a0d1 14-Sep-2017 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: delete in-kernel firmware

The last firmware change for the in-kernel firmware source code was back
in 2013. Everyone has been relying on the out-of-tree linux-firmware
package for a long long time.

So let's drop it, it's baggage we don't need to keep dragging around
(and having to fix random kbuild issues over time...)

Cc: Kyle McMartin <kyle@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Marek <mmarek@suse.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


# 569dbb88 03-Sep-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13


# 8e9b4667 20-Aug-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)

Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get
the absolute path of the directory because GNU Make 3.80, the minimal
supported version at that time, did not support $(abspath ...) or
$(realpath ...).

Commit 37d69ee30808 ("docs: bump minimal GNU Make version to 3.81")
dropped the GNU Make 3.80 support, so we are now allowed to use those
make-builtin helpers.

This conversion will provide better portability without relying on
the pwd command or its location /bin/pwd.

I am intentionally using $(realpath ...) instead $(abspath ...) in
some places. The difference between the two is $(realpath ...)
returns an empty string if the given path does not exist. It is
convenient in places where we need to error-out if the makefile fails
to create an output directory.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Thierry Reding <treding@nvidia.com>


# cc4a41fe 27-Aug-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc7


# 801d2e9f 18-Aug-2017 Shuah Khan <shuah@kernel.org>

Makefile: add kselftest-clean to PHONY target list

kselftest-clean isn't in the PHONY target list. Add it.

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 8c97023c 26-Jul-2017 Arnd Bergmann <arnd@arndb.de>

Kbuild: use -fshort-wchar globally

Commit 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi")
added the --no-wchar-size-warning to the Makefile to avoid this
harmless warning:

arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail

Changing kbuild to use thin archives instead of recursive linking
unfortunately brings the same warning back during the final link.

The kernel does not use wchar_t string literals at this point, and
xen does not use wchar_t at all (only efi_char16_t), so the flag
has no effect, but as pointed out by Jan Beulich, adding a wchar_t
string literal would be bad here.

Since wchar_t is always defined as u16, independent of the toolchain
default, always passing -fshort-wchar is correct and lets us
remove the Xen specific hack along with fixing the warning.

Link: https://patchwork.kernel.org/patch/9275217/
Fixes: 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 14ccee78 20-Aug-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc6


# ef954844 13-Aug-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc5


# 312a3d09 01-Aug-2017 Cao jin <caoj.fnst@cn.fujitsu.com>

kbuild: trivial cleanups on the comments

This is a bunch of trivial fixes and cleanups.

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# aae4e7a8 06-Aug-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc4


# 16f73eb0 30-Jul-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc3


# 520eccdf 23-Jul-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.13-rc2


# 18afab8c 17-Jul-2017 Mauro Carvalho Chehab <mchehab@kernel.org>

docs: Makefile: remove no-ops targets

After removal of DocBook, those targets are bogus.

Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 5771a8c0 15-Jul-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux v4.13-rc1


# bd664f6b 12-Jul-2017 Linus Torvalds <torvalds@linux-foundation.org>

disable new gcc-7.1.1 warnings for now

I made the mistake of upgrading my desktop to the new Fedora 26 that
comes with gcc-7.1.1.

There's nothing wrong per se that I've noticed, but I now have 1500
lines of warnings, mostly from the new format-truncation warning
triggering all over the tree.

We use 'snprintf()' and friends in a lot of places, and often know that
the numbers are fairly small (ie a controller index or similar), but gcc
doesn't know that, and sees an 'int', and thinks that it could be some
huge number. And then complains when our buffers are not able to fit
the name for the ten millionth controller.

These warnings aren't necessarily bad per se, and we probably want to
look through them subsystem by subsystem, but at least during the merge
window they just mean that I can't even see if somebody is introducing
any *real* problems when I pull.

So warnings disabled for now.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# d7f14c66 09-Jul-2017 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

kbuild: Enable Large File Support for hostprogs

This fixes the following build error for me when building on an 32 bit
machine using an XFS file system:

$ make scripts/basic/fixdep
HOSTCC scripts/basic/fixdep
fixdep: error fstat'ing depfile: scripts/basic/.fixdep.d: Value too large for defined data type

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a9d9a400 09-Jul-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: split exported generic header creation into uapi-asm-generic

When we install headers, we are interested only in headers under uapi
directories. Split out uapi-asm-generic target and make headers_install
depend on it. It will avoid generating unneeded asm-generic wrappers.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a8ff49a1 09-Jul-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: pass dst= to Makefile.headersinst from top Makefile

We can always pass dst= from the top Makefile. This will simplify
the logic in Makefile.headersinst.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 0f042eea 09-Jul-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: fix comment about dst of headers_{install, check}_all

Commit 61562f981e92 ("uapi: export all arch specifics directories")
changed the dst from asm-<arch> to arch-<arch> for headers_install_all
or headers_check_all. Update the comment.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6f7da290 02-Jul-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12


# c4e6fff1 29-Jun-2017 Cao jin <caoj.fnst@cn.fujitsu.com>

kbuild: improve comments on KBUILD_SRC

Original comments is confusing on "OBJ directory", make it clear.
Bonus: move comments close to what it wants to comment.

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 3a166fc2 19-Jun-2017 Nicholas Piggin <npiggin@gmail.com>

kbuild: handle libs-y archives separately from built-in.o archives

The thin archives build currently puts all lib.a and built-in.o
files together and links them with --whole-archive.

This works because thin archives can recursively refer to thin
archives. However some architectures include libgcc.a, which may
not be a thin archive, or it may not be constructed with the "P"
option, in which case its contents do not get linked correctly.

So don't pull .a libs into the root built-in.o archive. These
libs should already have symbol tables and indexes built, so they
can be direct linker inputs. Move them out of the --whole-archive
option, which restore the conditional linking behaviour of lib.a
to thin archives builds.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# c0bc126f 25-Jun-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc7


# 9f3f1fd2 21-Jun-2017 Matthias Kaehlcke <mka@chromium.org>

kbuild: Add __cc-option macro

cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines
whether an option is supported or not. This is fine for options used to
build the kernel itself, however some components like the x86 boot code
use a different set of flags.

Add the new macro __cc-option which is a more generic version of
cc-option with additional parameters. One parameter is the compiler
with which the check should be performed, the other the compiler options
to be used instead KBUILD_C*FLAGS.

Refactor cc-option and hostcc-option to use __cc-option and move
hostcc-option to scripts/Kbuild.include.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 52b3f239 23-Jun-2017 Jonathan Corbet <corbet@lwn.net>

Docs: clean up some DocBook loose ends

There were a few bits and pieces left over from the now-disused DocBook
toolchain; git rid of them.

Reported-by: Markus Heiser <markus.heiser@darmarit.de>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# bfb38988 21-Apr-2017 Matthias Kaehlcke <mka@chromium.org>

kbuild: clang: Disable 'address-of-packed-member' warning

clang generates plenty of these warnings in different parts of the code,
to an extent that the warnings are little more than noise. Disable the
'address-of-packed-member' warning.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 41f1830f 19-Jun-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc6


# 32c1431e 11-Jun-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc5


# f8224f7f 06-Jun-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: remove duplicated arch/*/include/generated/uapi include path

Commit 90ac086bca10 ("Makefile: include arch/*/include/generated/uapi
before .../generated") introduced this for bisect'ability. The commit
chose to promote arch/*/include/generated/uapi in the search path
rather than cleaning stale headers.

After all, we found that approach was not enough, and ended up with
cleaning stale headers by commit cda2c65f981d ("kbuild: Remove stale
asm-generic wrappers").

So, the extra search path is no longer needed because Kbuild invokes
scripts/Makefile.asm-generic and remove stale headers before it starts
descending.

This commit is also reverting commit dc33db7c338e ("Kbuild: avoid
duplicate include path") because we have no more duplicated path.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 9ba26a72 06-Jun-2017 Cao jin <caoj.fnst@cn.fujitsu.com>

Kbuild: tiny correction on `make help`

The help info of `make C=1` is little confusing, make it clear.

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 6f0fa58e 19-May-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: simplify silent build (-s) detection

This allows to detect -s (--silent) option without checking GNU Make
version.

As commit e36aaea28972 ("kbuild: Fix silent builds with make-4")
pointed out, GNU Make 4.x changed the way/order it presents the
command line options into MAKEFLAGS.

In Make 3.8x, 's' is always the first in a group of short options.
The group may be prefixed with '-' in some cases.

In Make 4.x, 's' is always the last in a group of short options.

As commit e6ac89fabd03 ("kbuild: Correctly deal with make options
which contain an 's'") addressed, we also need to deal with long
options that contain 's', like --warn-undefined-variables.

Test cases:

[1] command line input: make --silent
-> MAKEFLAGS for Make 3.8x: s
-> MAKEFLAGS for Make 4.x : s

[2] command line input: make -srR
-> MAKEFLAGS for Make 3.8x: sRr
-> MAKEFLAGS for Make 4.x : rRs

[3] command line input: make -s -rR --warn-undefined-variables
-> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr
-> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables

My idea to cater to all the cases more easily is to filter out long
options (--%), then search 's' with $(findstring ...). This way will
be more future-proof even if future versions of Make put 's' in the
middle of the group.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 3c2993b8 04-Jun-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc4


# 5ed02dbb 28-May-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc3


# 08332893 21-May-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc2


# 05d8cba4 15-May-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: skip install/check of headers right under uapi directories

Since commit 61562f981e92 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=$root/usr headers_install"
deletes standard glibc headers and others in $(root)/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with $(root)/usr/include for its
destination when installing asm headers. So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
$(root)/usr/include for its destination, it works around the problem
by creating an dummy destination $(root)/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip headers install/check
in include/uapi and arch/$(hdr-arch)/include/uapi because we know
there are only sub-directories in uapi directories. A good side
effect is the empty destination $(root)/usr/include/uapi will go
away.

I am also removing the trailing slash in the headers_check target to
skip checking in arch/$(hdr-arch)/include/uapi.

Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>


# cb43fb57 14-May-2017 Mauro Carvalho Chehab <mchehab@kernel.org>

docs: remove DocBook from the building system

Now that we don't have any DocBook anymore, remove it from
the building system.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>


# 2ea659a9 13-May-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.12-rc1


# 61562f98 27-Mar-2017 Nicolas Dichtel <nicolas.dichtel@6wind.com>

uapi: export all arch specifics directories

This patch removes the need of subdir-y. Now all files/directories under
arch/<arch>/include/uapi/ are exported.

The only change for userland is the layout of the command 'make
headers_install_all': directories asm-<arch> are replaced by arch-<arch>/.
Those new directories contains all files/directories of the specified arch.

Note that only cris and tile have more directories than only asm:
- arch-v[10|32] for cris;
- arch for tile.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 31b8cc80 08-May-2017 Randy Dunlap <rdunlap@infradead.org>

make help: add tools help target

Add a top-level Makefile help target for Userspace tools.

Also make each help "heading" end with a colon ':'.

Link: http://lkml.kernel.org/r/55c986ff-3966-3e47-2984-7349da2cce51@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# bd74370b 30-Apr-2017 Rabin Vincent <rabin@rab.in>

Makefile: evaluate LDFLAGS_BUILD_ID only once

Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only
once instead of over and over.

This provides a ~20% reduction in null build time with x86 allnoconfig:

$ make allnoconfig && make -j8
$ perf stat -r5 -e sched:sched_process_exec make -j8
- 2 119 sched:sched_process_exec
+ 1 878 sched:sched_process_exec

- 1,238817018 seconds time elapsed
+ 0,971020553 seconds time elapsed

Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a351e9b9 30-Apr-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11


# a37c45cd 25-Apr-2017 Michael Davidson <md@google.com>

kbuild: clang: add -no-integrated-as to KBUILD_[AC]FLAGS

The Linux Kernel relies on GCC's acceptance of inline assembly as an
opaque object which will not have any validation performed on the content.
The current behaviour in LLVM is to perform validation of the contents by
means of parsing the input if the MC layer can handle it.

Disable clangs integrated assembler and use the GNU assembler instead.

Wording-mostly-from: Saleem Abdulrasool <compnerd@compnerd.org>
Signed-off-by: Michael Davidson <md@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 433db3e2 24-Apr-2017 Vinícius Tinti <viniciustinti@gmail.com>

kbuild: Add support to generate LLVM assembly files

Add rules to kbuild in order to generate LLVM assembly files with the .ll
extension when using clang.

# from c code
make CC=clang kernel/pid.ll

Signed-off-by: Vinícius Tinti <viniciustinti@gmail.com>
Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 5a7ad114 23-Apr-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc8


# 785f11aa 21-Apr-2017 Behan Webster <behanw@converseincode.com>

kbuild: Add better clang cross build support

Add cross target to CC if using clang. Also add custom gcc toolchain
path for fallback gcc tools.

Clang will fallback to using things like ld, as, and libgcc if
(respectively) one of the llvm linkers isn't available, the integrated
assembler is turned off, or an appropriately cross-compiled version of
compiler-rt isn't available. To this end, you can specify the path to
this fallback gcc toolchain with GCC_TOOLCHAIN.

Signed-off-by: Behan Webster <behanw@converseincode.com>
Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: Mark Charlebois <charlebm@gmail.com>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# a0ae981e 12-Apr-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: drop -Wno-unknown-warning-option from clang options

Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), cc-option and friends work nicely
for clang.

However, -Wno-unknown-warning-option makes clang happy with any
unknown warning options even if -Werror is specified.

Once -Wno-unknown-warning-option is added, any succeeding call of
cc-disable-warning is evaluated positive, then unknown warning
options are accepted. This should be dropped.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 90ad4052 14-Apr-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7

Arnd Bergmann reported:
"When ftrace is enabled and we build with gcc-4.7 or older, we
get a warning for each file on architectures that select
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:

warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]
"

Since commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), warnings are treated as errors in
cc-option checks. CC_FLAGS_FTRACE is blindly added to KBUILD_CFLAGS,
so $(call cc-option,-ffunction-sections,) should be moved below it
in order to detect the conflict between the two options.

Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4f7d029b 16-Apr-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc7


# 6748cb3c 27-Mar-2017 Behan Webster <behanw@converseincode.com>

kbuild: use -Oz instead of -Os when using clang

This generates smaller resulting object code when compiled with clang.

Signed-off-by: Behan Webster <behanw@converseincode.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 39da7c50 09-Apr-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc6


# a71c9a1c 02-Apr-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc5


# 036db11c 24-Mar-2017 Cao jin <caoj.fnst@cn.fujitsu.com>

sparse doc: fix reference path

Documentation/sparse.txt has been moved to
Documentation/dev-tools/sparse.rst

Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# c02ed2e7 26-Mar-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc4


# c834f0e8 20-Mar-2017 Kees Cook <keescook@chromium.org>

Kbuild: make designated_init attribute fatal

If a structure is marked with __attribute__((designated_init)) from
GCC or Sparse, it needs to have all static initializers using designated
initialization. Fail the build for any missing cases. This attribute will
be used by the randstruct plugin to make sure randomized structures are
being correctly initialized.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 7292ae3d 20-Mar-2017 Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>

jump label: fix passing kbuild_cflags when checking for asm goto support

The latest change of asm goto support check added passing of KBUILD_CFLAGS
to compiler. When these flags reference gcc plugins that are not built yet,
the check fails.

When one runs "make bzImage" followed by "make modules", the kernel is always
built with HAVE_JUMP_LABEL disabled, while the modules are built depending on
CONFIG_JUMP_LABEL. If HAVE_JUMP_LABEL macro happens to be different, modules
are built with undefined references, e.g.:

ERROR: "static_key_slow_inc" [net/netfilter/xt_TEE.ko] undefined!
ERROR: "static_key_slow_dec" [net/netfilter/xt_TEE.ko] undefined!
ERROR: "static_key_slow_dec" [net/netfilter/nft_meta.ko] undefined!
ERROR: "static_key_slow_inc" [net/netfilter/nft_meta.ko] undefined!
ERROR: "nf_hooks_needed" [net/netfilter/ipvs/ip_vs.ko] undefined!
ERROR: "nf_hooks_needed" [net/ipv6/ipv6.ko] undefined!
ERROR: "static_key_count" [net/ipv6/ipv6.ko] undefined!
ERROR: "static_key_slow_inc" [net/ipv6/ipv6.ko] undefined!

This change moves the check before all these references are added
to KBUILD_CFLAGS. This is correct because subsequent KBUILD_CFLAGS
modifications are not relevant to this check.

Reported-by: Anton V. Boyarshinov <boyarsh@altlinux.org>
Fixes: 35f860f9ba6a ("jump label: pass kbuild_cflags when checking for asm goto support")
Cc: stable@vger.kernel.org # v4.10
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: David Lin <dtwlin@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 97da3854 19-Mar-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc3


# b334e19a 13-Jan-2017 Arnd Bergmann <arnd@arndb.de>

Kbuild: use cc-disable-warning consistently for maybe-uninitialized

In commit a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning
for "make W=1""), I reverted another change that happened to fix a problem
with old compilers, and now we get this report again with old compilers
(prior to gcc-4.8) and GCOV enabled:

cc1: warnings being treated as errors
drivers/gpu/drm/i915/intel_ringbuffer.c: In function 'intel_ring_setup_status_page':
drivers/gpu/drm/i915/intel_ringbuffer.c:438: error: 'mmio.reg' may be used uninitialized in this function
At top level:
>> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"

The problem is that we turn off the warning conditionally in a number
of places as we should, but one of them does it unconditionally.
Instead, change it to call cc-disable-warning as we do elsewhere.

The original patch that caused it was merged into linux-4.7, then
4.8 removed the change and 4.9 brought it back, so we probably want
a backport to 4.9 once this is merged.

Use a ':=' assignment instead of '=' to force the cc-disable-warning
call to only be evaluated once instead of every time.

Cc: stable@vger.kernel.org
Fixes: a76bcf557ef4 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")
Fixes: e72e2dfe7c16 ("gcov: disable -Wmaybe-uninitialized warning")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# f78271df 22-Jan-2017 Masahiro Yamada <yamada.masahiro@socionext.com>

kbuild: drop unneeded patterns '.*.orig' and '.*.rej' from distclean

The patterns '.*.orig' and '.*.rej' are cleaned away by '*.orig' and
'*.rej' seen two lines above.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# 4495c08e 12-Mar-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc2


# 35288e30 09-Mar-2017 Seung-Woo Kim <sw0312.kim@samsung.com>

Kbuild: fix file name in comment about extra gcc checks

Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn,
so the file name in comment needs to be fixed.

Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>


# c1ae3cfa 05-Mar-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.11-rc1


# 9f0c18ae 14-Feb-2017 Josh Poimboeuf <jpoimboe@redhat.com>

objtool: Fix CONFIG_STACK_VALIDATION=y warning for out-of-tree modules

When building a CONFIG_STACK_VALIDATION enabled kernel without the
libelf devel package installed, the Makefile prints a warning:

"Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel"

But when building an out-of-tree module, the warning doesn't show.
Instead it tries to use objtool, and the build fails with:

/bin/sh: ./tools/objtool/objtool: No such file or directory

Make sure the warning and the disabling of objtool occur in all cases,
by moving the CONFIG_STACK_VALIDATION checks outside the 'ifeq
($(KBUILD_EXTMOD),)' block in the Makefile.

Tested-By: Marc MERLIN <marc@merlins.org>
Suggested-by: Jessica Yu <jeyu@redhat.com>
Reported-by: Marc MERLIN <marc@merlins.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Jessica Yu <jeyu@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michal Marek <mmarek@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 3b27a0c85d70 ("objtool: Detect and warn if libelf is missing and don't break the build")
Link: http://lkml.kernel.org/r/b3088ae4a8698143d4851965793c61fec2135b1f.1487182864.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>


# c470abd4 19-Feb-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10


# 62924fd7 15-Feb-2017 Rémy Léone <remy.leone@gmail.com>

Add a target to check broken external links in the Documentation

Documentation shouldn't have broken links.
sphinx linkcheck builder scans all documents for external links, tries
to open them with urllib2, and writes an overview which ones are broken
and redirected to standard output and to output.txt in the output
directory.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rémy Léone <remy.leone@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>


# 7089db84 12-Feb-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc8


# d5adbfcd 05-Feb-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc7


# 35f860f9 03-Feb-2017 David Lin <dtwlin@google.com>

jump label: pass kbuild_cflags when checking for asm goto support

Some versions of ARM GCC compiler such as Android toolchain throws in a
'-fpic' flag by default. This causes the gcc-goto check script to fail
although some config would have '-fno-pic' flag in the KBUILD_CFLAGS.

This patch passes the KBUILD_CFLAGS to the check script so that the
script does not rely on the default config from different compilers.

Link: http://lkml.kernel.org/r/20170120234329.78868-1-dtwlin@google.com
Signed-off-by: David Lin <dtwlin@google.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Michal Marek <mmarek@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 566cf877 29-Jan-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc6


# e572d088 18-Jan-2017 Josh Poimboeuf <jpoimboe@redhat.com>

tools build: Add tools tree support for 'make -s'

When doing a kernel build with 'make -s', everything is silenced except
the objtool build. That's because the tools tree support for silent
builds is some combination of missing and broken.

Three changes are needed to fix it:

- Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
tools Makefiles can see it.

- tools/scripts/Makefile.include: fix the tools Makefiles' ability to
recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from
the top-level Makefile. This silences the "DESCEND objtool" message.

- tools/build/Makefile.build: add support to the tools Build files for
recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are
copied from the top-level Makefile. This silences all the object
compile/link messages.

Reported-and-Tested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Michal Marek <mmarek@suse.com>
Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>


# 7a308bb3 22-Jan-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc5


# 49def185 15-Jan-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc4


# a121103c 08-Jan-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc3


# 0c744ea4 01-Jan-2017 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc2


# 7ce7d89f 25-Dec-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.10-rc1


# 69973b83 11-Dec-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9


# 3e5de27e 04-Dec-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc8


# 86556392 02-Dec-2016 Nicolas Pitre <nico@fluxnic.net>

kbuild: fix building bzImage with CONFIG_TRIM_UNUSED_KSYMS enabled

When building a specific target such as bzImage, modules aren't normally
built. However if CONFIG_TRIM_UNUSED_KSYMS is enabled, no built modules
means none of the exported symbols are used and therefore they will all
be trimmed away from the final kernel. A subsequent "make modules" will
fail because modpost cannot find the needed symbols for those modules in
the kernel binary.

Let's make sure modules are also built whenever CONFIG_TRIM_UNUSED_KSYMS
is enabled and that the kernel binary is properly rebuilt accordingly.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# d3fc425e 30-Nov-2016 Nicolas Pitre <nico@fluxnic.net>

kbuild: make sure autoksyms.h exists early

Some people are able to trigger a race where autoksyms.h is used before
its empty version is even created. Let's create it at the same time as
the directory holding it is created.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Prarit Bhargava <prarit@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# e5517c2a 27-Nov-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc7


# 9c763584 20-Nov-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc6


# c6a38553 14-Nov-2016 Borislav Petkov <bp@suse.de>

kbuild: Steal gcc's pie from the very beginning

So Sebastian turned off the PIE for kernel builds but that was too late
- Kbuild.include already uses KBUILD_CFLAGS and trying to disable gcc
options with, say cc-disable-warning, fails:

gcc -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
...
-Wno-sign-compare -fno-asynchronous-unwind-tables -Wframe-address -c -x c /dev/null -o .31392.tmp
/dev/null:1:0: error: code model kernel does not support PIC mode

because that returns an error and we can't disable the warning. For
example in this case:

KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)

which leads to gcc issuing all those warnings again.

So let's turn off PIE/PIC at the earliest possible moment, when we
declare KBUILD_CFLAGS so that cc-disable-warning picks it up too.

Also, we need the $(call cc-option ...) because -fno-PIE is supported
since gcc v3.4 and our lowest supported gcc version is 3.2 right now.

Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: stable@vger.kernel.org
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>


# a25f0944 13-Nov-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc5


# a76bcf55 10-Nov-2016 Arnd Bergmann <arnd@arndb.de>

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>


# 8ae94224 04-Nov-2016 Sebastian Andrzej Siewior <bigeasy@linutronix.de>

kbuild: add -fno-PIE

Debian started to build the gcc with -fPIE by default so the kernel
build ends before it starts properly with:
|kernel/bounds.c:1:0: error: code model kernel does not support PIC mode

Also add to KBUILD_AFLAGS due to:

|gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S
|arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic

Tagging it stable so it is possible to compile recent stable kernels as
well.

Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>


# bc33b0ca 05-Nov-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc4


# a909d3e6 29-Oct-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc3


# 07d9a380 23-Oct-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc2


# 1001354c 15-Oct-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.9-rc1


# ef6000b4 12-Oct-2016 Linus Torvalds <torvalds@linux-foundation.org>

Disable the __builtin_return_address() warning globally after all

This affectively reverts commit 377ccbb48373 ("Makefile: Mute warning
for __builtin_return_address(>0) for tracing only") because it turns out
that it really isn't tracing only - it's all over the tree.

We already also had the warning disabled separately for mm/usercopy.c
(which this commit also removes), and it turns out that we will also
want to disable it for get_lock_parent_ip(), that is used for at least
TRACE_IRQFLAGS. Which (when enabled) ends up being all over the tree.

Steven Rostedt had a patch that tried to limit it to just the config
options that actually triggered this, but quite frankly, the extra
complexity and abstraction just isn't worth it. We have never actually
had a case where the warning is actually useful, so let's just disable
it globally and not worry about it.

Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


# 18489292 06-Oct-2016 Shuah Khan <shuah@kernel.org>

samples: move blackfin gptimers-example from Documentation

Move blackfin gptimers-example to samples and remove it from Documentation
Makefile. Update samples Kconfig and Makefile to build gptimers-example.

blackfin is the last CONFIG_BUILD_DOCSRC target in Documentation/Makefile.
Hence this patch also includes changes to remove CONFIG_BUILD_DOCSRC from
Makefile and lib/Kconfig.debug and updates VIDEO_PCI_SKELETON dependency
on BUILD_DOCSRC.

Documentation/Makefile is not deleted to avoid braking make htmldocs and
make distclean.

Acked-by: Michal Marek <mmarek@suse.com>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>


# c8d2bc9b 02-Oct-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.8


# 08895a8b 25-Sep-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.8-rc8


# 3be79886 18-Sep-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.8-rc7


# 9395452b 11-Sep-2016 Linus Torvalds <torvalds@linux-foundation.org>

Linux 4.8-rc6


# fbe6e37d 24-Aug-2016 Nicholas Piggin <npiggin@gmail.com>

kbuild: add arch specific post-link Makefile

Allow architectures to create arch/xxx/Makefile.postlink with targets
for vmlinux, modules.ko, and clean, which will be invoked after final
linking of vmlinux and modules.

powerpc will use this to check vmlinux linker relocations for sanity,
and may use it to fix up alternate instruction patch branch addresses.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.com>


# b67067f1 24-Aug-2016 Nicholas Piggin <npiggin@gmail.com>

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>


# c6935931