Skip to content
Snippets Groups Projects
  1. Aug 13, 2019
    • Andrii Nakryiko's avatar
      btf: rename /sys/kernel/btf/kernel into /sys/kernel/btf/vmlinux · 7fd78568
      Andrii Nakryiko authored
      
      Expose kernel's BTF under the name vmlinux to be more uniform with using
      kernel module names as file names in the future.
      
      Fixes: 341dfcf8 ("btf: expose BTF info through sysfs")
      Suggested-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      7fd78568
    • Andrii Nakryiko's avatar
      btf: expose BTF info through sysfs · 341dfcf8
      Andrii Nakryiko authored
      
      Make .BTF section allocated and expose its contents through sysfs.
      
      /sys/kernel/btf directory is created to contain all the BTFs present
      inside kernel. Currently there is only kernel's main BTF, represented as
      /sys/kernel/btf/kernel file. Once kernel modules' BTFs are supported,
      each module will expose its BTF as /sys/kernel/btf/<module-name> file.
      
      Current approach relies on a few pieces coming together:
      1. pahole is used to take almost final vmlinux image (modulo .BTF and
         kallsyms) and generate .BTF section by converting DWARF info into
         BTF. This section is not allocated and not mapped to any segment,
         though, so is not yet accessible from inside kernel at runtime.
      2. objcopy dumps .BTF contents into binary file and subsequently
         convert binary file into linkable object file with automatically
         generated symbols _binary__btf_kernel_bin_start and
         _binary__btf_kernel_bin_end, pointing to start and end, respectively,
         of BTF raw data.
      3. final vmlinux image is generated by linking this object file (and
         kallsyms, if necessary). sysfs_btf.c then creates
         /sys/kernel/btf/kernel file and exposes embedded BTF contents through
         it. This allows, e.g., libbpf and bpftool access BTF info at
         well-known location, without resorting to searching for vmlinux image
         on disk (location of which is not standardized and vmlinux image
         might not be even available in some scenarios, e.g., inside qemu
         during testing).
      
      Alternative approach using .incbin assembler directive to embed BTF
      contents directly was attempted but didn't work, because sysfs_proc.o is
      not re-compiled during link-vmlinux.sh stage. This is required, though,
      to update embedded BTF data (initially empty data is embedded, then
      pahole generates BTF info and we need to regenerate sysfs_btf.o with
      updated contents, but it's too late at that point).
      
      If BTF couldn't be generated due to missing or too old pahole,
      sysfs_btf.c handles that gracefully by detecting that
      _binary__btf_kernel_bin_start (weak symbol) is 0 and not creating
      /sys/kernel/btf at all.
      
      v2->v3:
      - added Documentation/ABI/testing/sysfs-kernel-btf (Greg K-H);
      - created proper kobject (btf_kobj) for btf directory (Greg K-H);
      - undo v2 change of reusing vmlinux, as it causes extra kallsyms pass
        due to initially missing  __binary__btf_kernel_bin_{start/end} symbols;
      
      v1->v2:
      - allow kallsyms stage to re-use vmlinux generated by gen_btf();
      
      Reviewed-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      341dfcf8
  2. Aug 09, 2019
  3. Aug 04, 2019
    • M. Vefa Bicakci's avatar
      kconfig: Clear "written" flag to avoid data loss · 0c5b6c28
      M. Vefa Bicakci authored
      
      Prior to this commit, starting nconfig, xconfig or gconfig, and saving
      the .config file more than once caused data loss, where a .config file
      that contained only comments would be written to disk starting from the
      second save operation.
      
      This bug manifests itself because the SYMBOL_WRITTEN flag is never
      cleared after the first call to conf_write, and subsequent calls to
      conf_write then skip all of the configuration symbols due to the
      SYMBOL_WRITTEN flag being set.
      
      This commit resolves this issue by clearing the SYMBOL_WRITTEN flag
      from all symbols before conf_write returns.
      
      Fixes: 8e2442a5 ("kconfig: fix missing choice values in auto.conf")
      Cc: linux-stable <stable@vger.kernel.org> # 4.19+
      Signed-off-by: default avatarM. Vefa Bicakci <m.v.b@runbox.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      0c5b6c28
  4. Jul 31, 2019
    • Stephen Boyd's avatar
      kbuild: Check for unknown options with cc-option usage in Kconfig and clang · e8de12fb
      Stephen Boyd authored
      If the particular version of clang a user has doesn't enable
      -Werror=unknown-warning-option by default, even though it is the
      default[1], then make sure to pass the option to the Kconfig cc-option
      command so that testing options from Kconfig files works properly.
      Otherwise, depending on the default values setup in the clang toolchain
      we will silently assume options such as -Wmaybe-uninitialized are
      supported by clang, when they really aren't.
      
      A compilation issue only started happening for me once commit
      589834b3 ("kbuild: Add -Werror=unknown-warning-option to
      CLANG_FLAGS") was applied on top of commit b303c6df ("kbuild:
      compute false-positive -Wmaybe-uninitialized cases in Kconfig"). This
      leads kbuild to try and test for the existence of the
      -Wmaybe-uninitialized flag with the cc-option command in
      scripts/Kconfig.include, and it doesn't see an error returned from the
      option test so it sets the config value to Y. Then the Makefile tries to
      pass the unknown option on the command line and
      -Werror=unknown-warning-option catches the invalid option and breaks the
      build. Before commit 589834b3 ("kbuild: Add
      -Werror=unknown-warning-option to CLANG_FLAGS") the build works fine,
      but any cc-option test of a warning option in Kconfig files silently
      evaluates to true, even if the warning option flag isn't supported on
      clang.
      
      Note: This doesn't change cc-option usages in Makefiles because those
      use a different rule that includes KBUILD_CFLAGS by default (see the
      __cc-option command in scripts/Kbuild.incluide). The KBUILD_CFLAGS
      variable already has the -Werror=unknown-warning-option flag set. Thanks
      to Doug for pointing out the different rule.
      
      [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
      
      
      Cc: Peter Smith <peter.smith@linaro.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Douglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarStephen Boyd <swboyd@chromium.org>
      Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      e8de12fb
    • Masahiro Yamada's avatar
      kbuild: modpost: do not parse unnecessary rules for vmlinux modpost · a721588d
      Masahiro Yamada authored
      
      Since commit ff9b45c5 ("kbuild: modpost: read modules.order instead
      of $(MODVERDIR)/*.mod"), 'make vmlinux' emits a warning, like this:
      
      $ make defconfig vmlinux
        [ snip ]
        LD      vmlinux.o
      cat: modules.order: No such file or directory
        MODPOST vmlinux.o
        MODINFO modules.builtin.modinfo
        KSYM    .tmp_kallsyms1.o
        KSYM    .tmp_kallsyms2.o
        LD      vmlinux
        SORTEX  vmlinux
        SYSMAP  System.map
      
      When building only vmlinux, KBUILD_MODULES is not set. Hence, the
      modules.order is not generated. For the vmlinux modpost, it is not
      necessary at all.
      
      Separate scripts/Makefile.modpost for the vmlinux/modules stages.
      This works more efficiently because the vmlinux modpost does not
      need to include .*.cmd files.
      
      Fixes: ff9b45c5 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod")
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      a721588d
    • Masahiro Yamada's avatar
      kbuild: modpost: remove unnecessary dependency for __modpost · acf2a139
      Masahiro Yamada authored
      
      __modpost is a phony target. The dependency on FORCE is pointless.
      All the objects have been built in the previous stage, so the
      dependency on the objects are not necessary either.
      
      Count the number of modules in a more straightforward way.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      acf2a139
    • Masahiro Yamada's avatar
      kbuild: modpost: handle KBUILD_EXTRA_SYMBOLS only for external modules · cb481993
      Masahiro Yamada authored
      
      KBUILD_EXTRA_SYMBOLS makes sense only when building external modules.
      Moreover, the modpost sets 'external_module' if the -e option is given.
      
      I replaced $(patsubst %, -e %,...) with simpler $(addprefix -e,...)
      while I was here.
      
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      cb481993
    • Masahiro Yamada's avatar
      kbuild: modpost: include .*.cmd files only when targets exist · 944cfe9b
      Masahiro Yamada authored
      
      If a build rule fails, the .DELETE_ON_ERROR special target removes the
      target, but does nothing for the .*.cmd file, which might be corrupted.
      So, .*.cmd files should be included only when the corresponding targets
      exist.
      
      Commit 392885ee ("kbuild: let fixdep directly write to .*.cmd
      files") missed to fix up this file.
      
      Fixes: 392885ee ("kbuild: let fixdep directly write to .*.cmd")
      Cc: <stable@vger.kernel.org> # v5.0+
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      944cfe9b
  5. Jul 30, 2019
  6. Jul 29, 2019
  7. Jul 27, 2019
  8. Jul 17, 2019
Loading