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/577Suggested-by: NDmitry Golovin <dima@golovin.in>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

modules.order is a real target. Split its build rule out like
modules.builtin
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

In commit ebcc5928 ("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 c3f0d0bc ("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/517Suggested-by: NPeter Smith <peter.smith@linaro.org>
Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Now that hdr-inst is used only in the top Makefile, move it there
from scripts/Kbuild.include.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit fcc8487d ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

Since commit 2aedcd09 ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>

Commit 5318321d ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>

'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: NMasahiro Yamada <yamada.masahiro@socionext.com>

Commit 8e2faea8 ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>

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: NDan Rue <dan.rue@linaro.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>

For *-pkg targets, the LICENSES directory should be included in the
source tarball.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

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 9390dff6 ("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: 9390dff6 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing")
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>

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/cb3f812b6b9fab8f3b41414f24e90222170417b4Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NNathan Chancellor <natechancellor@gmail.com>
Acked-by: NKees Cook <keescook@chromium.org>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>

This warning was disabled by commit bd664f6b ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnd Bergmann <arnd@arndb.de>

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: NGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: NGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: NAlexey Gladkov <gladkov.alexey@gmail.com>
Acked-by: NJessica Yu <jeyu@kernel.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

A minor code cleanup.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NLinus Torvalds <torvalds@linux-foundation.org>

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: NAlexander Potapenko <glider@google.com>
Signed-off-by: NAlexander Potapenko <glider@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Tested-by: NAlexander Potapenko <glider@google.com>
Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMasahiro Yamada <yamada.masahiro@socionext.com>

This is unneeded since commit 43fee2b2 ("kbuild: do not redirect
the first prerequisite for filechk").
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NGiovanni Gherdovich <ggherdovich@suse.cz>
Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NPetr Mladek <pmladek@suse.com>