Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 5月, 2019 5 次提交
  3. 07 5月, 2019 1 次提交
    • A
      moduleparam: Save information about built-in modules in separate file · 898490c0
      由 Alexey Gladkov 提交于 
      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>
      898490c0
  5. 06 5月, 2019 1 次提交
  7. 03 5月, 2019 2 次提交
  9. 02 5月, 2019 1 次提交
  11. 29 4月, 2019 1 次提交
  13. 25 4月, 2019 1 次提交
    • K
      security: Implement Clang's stack initialization · 709a972e
      由 Kees Cook 提交于 
      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>
      709a972e
  15. 22 4月, 2019 1 次提交
  17. 15 4月, 2019 1 次提交
  19. 09 4月, 2019 2 次提交
  21. 08 4月, 2019 2 次提交
  23. 03 4月, 2019 1 次提交
    • A
      kbuild: add ability to generate BTF type info for vmlinux · e83b9f55
      由 Andrii Nakryiko 提交于 
      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: NAndrii Nakryiko <andriin@fb.com>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      e83b9f55
  25. 02 4月, 2019 2 次提交
    • M
      kbuild: use $(srctree) instead of KBUILD_SRC to check out-of-tree build · a9a49c2a
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      a9a49c2a
    • M
      kbuild: allow Kbuild to start from any directory · 25b146c5
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: NKieran Bingham <kbingham@kernel.org>
      25b146c5
  27. 01 4月, 2019 4 次提交
  29. 28 3月, 2019 3 次提交
  31. 25 3月, 2019 1 次提交
  33. 21 3月, 2019 1 次提交
  35. 20 3月, 2019 1 次提交
  37. 18 3月, 2019 1 次提交
  39. 17 3月, 2019 2 次提交
    • M
      kbuild: force all architectures except um to include mandatory-y · 037fc336
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      037fc336
    • D
      kbuild: Make NOSTDINC_FLAGS a simply expanded variable · 0c22be07
      由 Douglas Anderson 提交于 
      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 e8f5bdb0 ("[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: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      0c22be07
  41. 14 3月, 2019 1 次提交
    • M
      kbuild: add workaround for Debian make-kpkg · 2b50f7ab
      由 Masahiro Yamada 提交于 
      Since commit 3812b8c5 ("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: 3812b8c5 ("kbuild: make -r/-R effective in top Makefile for old Make versions")
Reported-by: NLiz Zhang <lizzha@microsoft.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NLili Deng <v-lide@microsoft.com>
Cc: Manoj Srivastava <srivasta@debian.org>
      2b50f7ab
  43. 05 3月, 2019 1 次提交
  45. 04 3月, 2019 3 次提交
  47. 28 2月, 2019 1 次提交