Since commit 61562f98 ("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: 61562f98 ("uapi: export all arch specifics directories")
Reported-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NDan Williams <dan.j.williams@intel.com>
Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>

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: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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.orgSigned-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NRabin Vincent <rabin@rab.in>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMichael Davidson <md@google.com>
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NVinícius Tinti <viniciustinti@gmail.com>
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Signed-off-by: NGreg Hackmann <ghackmann@google.com>
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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

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 c3f0d0bc ("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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

This generates smaller resulting object code when compiled with clang.
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

Documentation/sparse.txt has been moved to
Documentation/dev-tools/sparse.rst
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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

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: NAnton V. Boyarshinov <boyarsh@altlinux.org>
Fixes: 35f860f9 ("jump label: pass kbuild_cflags when checking for asm goto support")
Cc: stable@vger.kernel.org	# v4.10
Signed-off-by: NGleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: NDmitry V. Levin <ldv@altlinux.org>
Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: NDavid Lin <dtwlin@google.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

In commit a76bcf55 ("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: a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")
Fixes: e72e2dfe ("gcov: disable -Wmaybe-uninitialized warning")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

The patterns '.*.orig' and '.*.rej' are cleaned away by '*.orig' and
'*.rej' seen two lines above.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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: NMarc MERLIN <marc@merlins.org>
Suggested-by: NJessica Yu <jeyu@redhat.com>
Reported-by: NMarc MERLIN <marc@merlins.org>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: NJessica 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: 3b27a0c8 ("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.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

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: NJani Nikula <jani.nikula@intel.com>
Tested-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRémy Léone <remy.leone@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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.comSigned-off-by: NDavid Lin <dtwlin@google.com>
Acked-by: NSteven Rostedt <rostedt@goodmis.org>
Cc: Michal Marek <mmarek@suse.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NJosh 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.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>