Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 3月, 2018 1 次提交
  3. 19 3月, 2018 1 次提交
  5. 12 3月, 2018 1 次提交
  7. 05 3月, 2018 1 次提交
  9. 02 3月, 2018 1 次提交
  11. 01 3月, 2018 2 次提交
    • L
      kbuild: disable sparse warnings about unknown attributes · 6c49f359
      由 Luc Van Oostenryck 提交于 
      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=151871725417322Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Tested-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6c49f359
    • U
      Makefile: Fix lying comment re. silentoldconfig · 61277981
      由 Ulf Magnusson 提交于 
      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: NUlf Magnusson <ulfalizer@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      61277981
  13. 26 2月, 2018 1 次提交
  15. 21 2月, 2018 1 次提交
  17. 19 2月, 2018 1 次提交
  19. 12 2月, 2018 1 次提交
  21. 07 2月, 2018 5 次提交
  23. 29 1月, 2018 1 次提交
  25. 22 1月, 2018 1 次提交
  27. 15 1月, 2018 1 次提交
  29. 08 1月, 2018 1 次提交
  31. 01 1月, 2018 1 次提交
  33. 31 12月, 2017 1 次提交
    • L
      kbuild: add '-fno-stack-check' to kernel build options · 3ce120b1
      由 Linus Torvalds 提交于 
      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: NAlexander Tsoy <alexander@tsoy.me>
Reported-and-tested-by: NToralf 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: NLinus Torvalds <torvalds@linux-foundation.org>
      3ce120b1
  35. 24 12月, 2017 1 次提交
  37. 18 12月, 2017 1 次提交
  39. 16 12月, 2017 1 次提交
  41. 11 12月, 2017 1 次提交
  43. 06 12月, 2017 1 次提交
  45. 04 12月, 2017 1 次提交
  47. 27 11月, 2017 1 次提交
  49. 23 11月, 2017 3 次提交
  51. 18 11月, 2017 3 次提交
    • M
      kbuild: create built-in.o automatically if parent directory wants it · f7adc312
      由 Masahiro Yamada 提交于 
      "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 4b024242 ("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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      f7adc312
    • B
      kbuild: /bin/pwd -> pwd · 16f8259c
      由 Bjørn Forsman 提交于 
      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 028568d8
("kbuild: revert $(realpath ...) to $(shell cd ... && /bin/pwd)").
Signed-off-by: NBjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      16f8259c
    • V
      Makefile: support flag -fsanitizer-coverage=trace-cmp · d677a4d6
      由 Victor Chibotaru 提交于 
      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.comSigned-off-by: NVictor Chibotaru <tchibo@google.com>
Signed-off-by: NAlexander 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d677a4d6
  53. 16 11月, 2017 2 次提交
  55. 13 11月, 2017 3 次提交
    • M
      kbuild: do not call cc-option before KBUILD_CFLAGS initialization · 433dc2eb
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      433dc2eb
    • D
      kbuild: Cache a few more calls to the compiler · 4e562071
      由 Douglas Anderson 提交于 
      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: NDouglas Anderson <dianders@chromium.org>
Tested-by: NIngo Molnar <mingo@kernel.org>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      4e562071
    • D
      kbuild: Add a cache for generated variables · 3298b690
      由 Douglas Anderson 提交于 
      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: NDouglas Anderson <dianders@chromium.org>
Tested-by: NIngo Molnar <mingo@kernel.org>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      3298b690