Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
  • v5.4.106-ti-r42-bn
  • v5.10.168-ti-arm64-r105-mikrobus-additions
  • iio_channel_split
  • jkridner-5.10-arm64-patch-52743
  • 5.10-arm64
  • 5.10-rt
  • 5.10
  • 4.19-rt
  • 4.19
  • 5.4-rt
  • 5.4
  • master default protected
  • 4.14
  • 4.14-rt
  • v3.8.13-bone86
  • 4.19-xenomai
  • 5.4-xenomai
  • 5.4-arm64
  • 4.14-xenomai
  • v5.8.4-tupper-greybus
  • v5.4.106-ti-r42-bn1
  • v5.4.106-ti-r42-bn2
  • 5.10.153-ti-arm64-r84
  • 5.10.153-ti-arm64-r83
  • 5.10.153-ti-arm64-r82
  • 5.10.153-ti-arm64-r81
  • 5.10.153-ti-arm64-r80
  • 5.10.153-ti-arm64-r79
  • 5.10.145-ti-r55
  • 5.10.145-ti-rt-r55
  • 5.10.145-ti-arm64-r78
  • 5.10.145-ti-arm64-r77
  • 5.10.145-ti-arm64-r76
  • 5.10.145-ti-arm64-r75
  • 5.10.145-ti-arm64-r74
  • 5.10.145-ti-rt-r54
  • 5.10.145-ti-r54
  • 5.10.145-ti-arm64-r73
  • 5.10.145-ti-r53
  • 5.10.145-ti-rt-r53
40 results
Search by author
  • Any Author
  • Jason Kridner Jason Kridner jkridner
1 author
  1. Jan 20, 2022
  3. Jan 18, 2022
  5. Jan 15, 2022
  7. Jan 13, 2022
    • Yinan Liu's avatar
      scripts: ftrace - move the sort-processing in ftrace_init · 72b3942a
      Yinan Liu authored 
      When the kernel starts, the initialization of ftrace takes
up a portion of the time (approximately 6~8ms) to sort mcount
addresses. We can save this time by moving mcount-sorting to
compile time.

Link: https://lkml.kernel.org/r/20211212113358.34208-2-yinan@linux.alibaba.com



Signed-off-by: default avatarYinan Liu <yinan@linux.alibaba.com>
Reported-by: default avatarkernel test robot <lkp@intel.com>
Reported-by: default avatarkernel test robot <oliver.sang@intel.com>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      72b3942a
    • Masahiro Yamada's avatar
      kbuild: add cmd_file_size · c4d7f40b
      Masahiro Yamada authored 
      
Some architectures support self-extracting kernel, which embeds the
compressed vmlinux.

It has 4 byte data at the end so the decompressor can know the vmlinux
size beforehand.

GZIP natively has it in the trailer, but for the other compression
algorithms, the hand-crafted trailer is added.

It is unneeded to generate such _corrupted_ compressed files because
it is possible to pass the size data as a separate file.

For example, the assembly code:

     .incbin "compressed-vmlinux-with-size-data"

can be transformed to:

     .incbin "compressed-vmlinux"
     .incbin "size-data"

My hope is, after some reworks of the decompressors, the macros
cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}_with_size will go away.

This new macro, cmd_file_size, will be useful to generate a separate
size-data file.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      c4d7f40b
    • Masahiro Yamada's avatar
      kbuild: rename cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22} · 7ce7e984
      Masahiro Yamada authored 
      GZIP-compressed files end with 4 byte data that represents the size
of the original input. The decompressors (the self-extracting kernel)
exploit it to know the vmlinux size beforehand. To mimic the GZIP's
trailer, Kbuild provides cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}.
Unfortunately these macros are used everywhere despite the appended
size data is only useful for the decompressors.

There is no guarantee that such hand-crafted trailers are safely ignored.
In fact, the kernel refuses compressed initramdfs with the garbage data.
That is why usr/Makefile overrides size_append to make it no-op.

To limit the use of such broken compressed files, this commit renames
the existing macros as follows:

  cmd_bzip2   --> cmd_bzip2_with_size
  cmd_lzma    --> cmd_lzma_with_size
  cmd_lzo     --> cmd_lzo_with_size
  cmd_lz4     --> cmd_lz4_with_size
  cmd_xzkern  --> cmd_xzkern_with_size
  cmd_zstd22  --> cmd_zstd22_with_size

To keep the decompressors working, I...
      7ce7e984
    • Masahiro Yamada's avatar
      kbuild: drop $(size_append) from cmd_zstd · 64d8aaa4
      Masahiro Yamada authored 
      The appended file size is only used by the decompressors, which some
architectures support.

As the comment "zstd22 is used for kernel compression" says, cmd_zstd22
is used in arch/{mips,s390,x86}/boot/compressed/Makefile.

On the other hand, there is no good reason to append the file size to
cmd_zstd since it is used for other purposes.

Actually cmd_zstd is only used in usr/Makefile, where the appended file
size is rather harmful.

The initramfs with its file size appended is considered as corrupted
data, so commit 65e00e04

 ("initramfs: refactor the initramfs build
rules") added 'override size_append := :' to make it no-op.

As a conclusion, this $(size_append) should not exist here.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      64d8aaa4
  9. Jan 08, 2022
    • Masahiro Yamada's avatar
      certs: move scripts/extract-cert to certs/ · 340a0253
      Masahiro Yamada authored 
      
extract-cert is only used in certs/Makefile.

Move it there and build extract-cert on demand.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      340a0253
    • Masahiro Yamada's avatar
      kbuild: do not quote string values in include/config/auto.conf · 129ab0d2
      Masahiro Yamada authored 
      
The previous commit fixed up all shell scripts to not include
include/config/auto.conf.

Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.

Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):

    CONFIG_X="foo bar"

Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.

There are some patterns:

  [1] $(patsubst "%",%,$(CONFIG_X))
  [2] $(CONFIG_X:"%"=%)
  [3] $(subst ",,$(CONFIG_X))
  [4] $(shell echo $(CONFIG_X))

These are not only ugly, but also fragile.

[1] and [2] do not work if the value contains spaces, like
   CONFIG_X=" foo bar "

[3] does not work correctly if the value contains double-quotes like
   CONFIG_X="foo\"bar"

[4] seems to work better, but has a cost of forking a process.

Anyway, quoted strings were always PITA for our Makefiles.

This commit changes Kconfig to stop quoting in include/config/auto.conf.

These are the string type symbols referenced in Makefiles or scripts:

    ACPI_CUSTOM_DSDT_FILE
    ARC_BUILTIN_DTB_NAME
    ARC_TUNE_MCPU
    BUILTIN_DTB_SOURCE
    CC_IMPLICIT_FALLTHROUGH
    CC_VERSION_TEXT
    CFG80211_EXTRA_REGDB_KEYDIR
    EXTRA_FIRMWARE
    EXTRA_FIRMWARE_DIR
    EXTRA_TARGETS
    H8300_BUILTIN_DTB
    INITRAMFS_SOURCE
    LOCALVERSION
    MODULE_SIG_HASH
    MODULE_SIG_KEY
    NDS32_BUILTIN_DTB
    NIOS2_DTB_SOURCE
    OPENRISC_BUILTIN_DTB
    SOC_CANAAN_K210_DTB_SOURCE
    SYSTEM_BLACKLIST_HASH_LIST
    SYSTEM_REVOCATION_KEYS
    SYSTEM_TRUSTED_KEYS
    TARGET_CPU
    UNUSED_KSYMS_WHITELIST
    XILINX_MICROBLAZE0_FAMILY
    XILINX_MICROBLAZE0_HW_VER
    XTENSA_VARIANT_NAME

I checked them one by one, and fixed up the code where necessary.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      129ab0d2
    • Masahiro Yamada's avatar
      kbuild: do not include include/config/auto.conf from shell scripts · 7d153696
      Masahiro Yamada authored 
      Richard Weinberger pointed out the risk of sourcing the kernel config
from shell scripts [1], and proposed some patches [2], [3]. It is a good
point, but it took a long time because I was wondering how to fix this.

This commit goes with simple grep approach because there are only a few
scripts including the kernel configuration.

scripts/link_vmlinux.sh has references to a bunch of CONFIG options,
all of which are boolean. I added is_enabled() helper as
scripts/package/{mkdebian,builddeb} do.

scripts/gen_autoksyms.sh uses 'eval', stating "to expand the whitelist
path". I removed it since it is the issue we are trying to fix.

I was a bit worried about the cost of invoking the grep command over
again. I extracted the grep parts from it, and measured the cost. It
was approximately 0.03 sec, which I hope is acceptable.

[test code]

  $ cat test-grep.sh
  #!/bin/sh

  is_enabled() {
          grep -q "^$1=y" include/config/auto.conf
  }

  is_enabled CONFIG_LTO_CLANG
  is_enabled CONFIG_LTO_CLANG
  is_enabled CONFIG_STACK_VALIDATION
  is_enabled CONFIG_UNWINDER_ORC
  is_enabled CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
  is_enabled CONFIG_VMLINUX_VALIDATION
  is_enabled CONFIG_FRAME_POINTER
  is_enabled CONFIG_GCOV_KERNEL
  is_enabled CONFIG_LTO_CLANG
  is_enabled CONFIG_RETPOLINE
  is_enabled CONFIG_X86_SMAP
  is_enabled CONFIG_LTO_CLANG
  is_enabled CONFIG_VMLINUX_MAP
  is_enabled CONFIG_KALLSYMS_ALL
  is_enabled CONFIG_KALLSYMS_ABSOLUTE_PERCPU
  is_enabled CONFIG_KALLSYMS_BASE_RELATIVE
  is_enabled CONFIG_DEBUG_INFO_BTF
  is_enabled CONFIG_KALLSYMS
  is_enabled CONFIG_DEBUG_INFO_BTF
  is_enabled CONFIG_BPF
  is_enabled CONFIG_BUILDTIME_TABLE_SORT
  is_enabled CONFIG_KALLSYMS

  $ time ./test-grep.sh
  real    0m0.036s
  user    0m0.027s
  sys     m0.009s

[1]: https://lore.kernel.org/all/1919455.eZKeABUfgV@blindfold/
[2]: https://lore.kernel.org/all/20180219092245.26404-1-richard@nod.at/
[3]: https://lore.kernel.org/all/20210920213957.1064-2-richard@nod.at/


Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      7d153696
    • Masahiro Yamada's avatar
      certs: simplify $(srctree)/ handling and remove config_filename macro · b8c96a6b
      Masahiro Yamada authored 
      
The complex macro, config_filename, was introduced to do:

 [1] drop double-quotes from the string value
 [2] add $(srctree)/ prefix in case the file is not found in $(objtree)
 [3] escape spaces and more

[1] will be more generally handled by Kconfig later.

As for [2], Kbuild uses VPATH to search for files in $(objtree),
$(srctree) in this order. GNU Make can natively handle it.

As for [3], converting $(space) to $(space_escape) back and forth looks
questionable to me. It is well-known that GNU Make cannot handle file
paths with spaces in the first place.

Instead of using the complex macro, use $< so it will be expanded to
the file path of the key.

Remove config_filename, finally.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      b8c96a6b
    • Masahiro Yamada's avatar
      kbuild: stop using config_filename in scripts/Makefile.modsign · 4db9c2e3
      Masahiro Yamada authored 
      
Toward the goal of removing the config_filename macro, drop
the double-quotes and add $(srctree)/ prefix in an ad hoc way.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      4db9c2e3
    • Masahiro Yamada's avatar
      kbuild: move headers_check.pl to usr/include/ · 50a48340
      Masahiro Yamada authored 
      
This script is only used by usr/include/Makefile. Make it local to
the directory.

Update the comment in include/uapi/linux/soundcard.h because
'make headers_check' is no longer functional.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      50a48340
  11. Jan 07, 2022
  13. Jan 05, 2022
    • Jisheng Zhang's avatar
      riscv: extable: add `type` and `data` fields · 2bf847db
      Jisheng Zhang authored 
      This is a riscv port of commit d6e2cc56

 ("arm64: extable: add `type`
and `data` fields").

Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Unverified
      2bf847db
    • Jisheng Zhang's avatar
      riscv: switch to relative exception tables · bb1f85d6
      Jisheng Zhang authored 
      
Similar as other architectures such as arm64, x86 and so on, use
offsets relative to the exception table entry values rather than
absolute addresses for both the exception locationand the fixup.

However, RISCV label difference will actually produce two relocations,
a pair of R_RISCV_ADD32 and R_RISCV_SUB32. Take below simple code for
example:

$ cat test.S
.section .text
1:
        nop
.section __ex_table,"a"
        .balign 4
        .long (1b - .)
.previous

$ riscv64-linux-gnu-gcc -c test.S
$ riscv64-linux-gnu-readelf -r test.o
Relocation section '.rela__ex_table' at offset 0x100 contains 2 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000600000023 R_RISCV_ADD32     0000000000000000 .L1^B1 + 0
000000000000  000500000027 R_RISCV_SUB32     0000000000000000 .L0  + 0

The modpost will complain the R_RISCV_SUB32 relocation, so we need to
patch modpost.c to skip this relocation for .rela__ex_table section.

After this patch, the __ex_table section size of defconfig vmlinux is
reduced from 7072 Bytes to 3536 Bytes.

Signed-off-by: default avatarJisheng Zhang <jszhang@kernel.org>
Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Unverified
      bb1f85d6
    • Mark Rutland's avatar
      scripts/sorttable: Unify arm64 & x86 sort functions · e232333b
      Mark Rutland authored 
      The format of the arm64 and x86 exception table entries is essentially
the same as of commits:

  46d28947 ("x86/extable: Rework the exception table mechanics")
  d6e2cc56

 ("arm64: extable: add `type` and `data` fields")

Both use a 12-byte entry consisting of two 32-bit relative offsets and
32 bits of (absolute) data, and their sort functions are identical aside
from commentary, with arm64 saying:

   /* Don't touch the fixup type or data */

... and x86 saying:

  /* Don't touch the fixup type */

Unify the two behind a common sort_relative_table_with_data() function,
retaining the arm64 commentary.

There should be no functional change as a result of this patch.

Signed-off-by: default avatarMark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Unverified
      e232333b
  15. Jan 04, 2022
  17. Jan 03, 2022
  19. Dec 24, 2021
  21. Dec 17, 2021
  23. Dec 16, 2021
  25. Dec 12, 2021
  27. Dec 11, 2021
  29. Dec 09, 2021
  31. Dec 02, 2021
    • Nathan Chancellor's avatar
      Documentation: Raise the minimum supported version of LLVM to 11.0.0 · df05c0e9
      Nathan Chancellor authored 
      LLVM versions prior to 11.0.0 have a harder time with dead code
elimination, which can cause issues with commonly used expressions such
as BUILD_BUG_ON and the bitmask functions/macros in bitfield.h (see the
first two issues links below).

Whenever there is an issue within LLVM that has been resolved in a later
release, the only course of action is to gate the problematic
configuration or source code on the toolchain verson or raise the
minimum supported version of LLVM for building the kernel, as LLVM has a
limited support lifetime compared to GCC. GCC major releases will
typically see a few point releases across a two year period on average
whereas LLVM major releases are only supported until the next major
release and will only see one or two point releases within that
timeframe. For example, GCC 8.1 was released in May 2018 and GCC 8.5 was
released in May 2021, whereas LLVM 12.0.0 was released in April 2021 and
its only point release, 12.0.1, was released in July 2021, giving a
minimal window for fixes to be backported.

To resolve these build errors around improper dead code elimination,
raise the minimum supported version of LLVM for building the kernel to
11.0.0. Doing so is a more proper solution than mucking around with core
kernel macros that have always worked with GCC or disabling drivers for
using these macros in a proper manner. This type of issue may continue
to crop up and require patching, which creates more debt for bumping the
minimum supported version in the future.

This should have a minimal impact to distributions. Using a script to
pull several different Docker images and check the output of
'clang --version':

archlinux:latest: clang version 13.0.0

debian:oldoldstable-slim: clang version 3.8.1-24 (tags/RELEASE_381/final)
debian:oldstable-slim: clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final)
debian:stable-slim: Debian clang version 11.0.1-2
debian:testing-slim: Debian clang version 11.1.0-4
debian:unstable-slim: Debian clang version 11.1.0-4

fedora:34: clang version 12.0.1 (Fedora 12.0.1-1.fc34)
fedora:latest: clang version 13.0.0 (Fedora 13.0.0-3.fc35)
fedora:rawhide: clang version 13.0.0 (Fedora 13.0.0-5.fc36)

opensuse/leap:15.2: clang version 9.0.1
opensuse/leap:latest: clang version 11.0.1
opensuse/tumbleweed:latest: clang version 13.0.0

ubuntu:bionic: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
ubuntu:latest: clang version 10.0.0-4ubuntu1
ubuntu:hirsute: Ubuntu clang version 12.0.0-3ubuntu1~21.04.2
ubuntu:rolling: Ubuntu clang version 13.0.0-2
ubuntu:devel: Ubuntu clang version 13.0.0-9

In every case, the distribution's version of clang is either older than
the current minimum supported version of LLVM 10.0.1 or equal to or
greater than the proposed 11.0.0 so nothing should change.

Another benefit of this change is LLVM=1 works better with arm64 and
x86_64 since commit f12b034a ("scripts/Makefile.clang: default to
LLVM_IAS=1") enabled the integrated assembler by default, which only
works well with clang 11+ (clang-10 required it to be disabled to
successfully build a kernel).

Link: https://github.com/ClangBuiltLinux/linux/issues/1293
Link: https://github.com/ClangBuiltLinux/linux/issues/1506
Link: https://github.com/ClangBuiltLinux/linux/issues/1511
Link: https://github.com/llvm/llvm-project/commit/fa496ce3c6774097080c8a9cb808da56f383b938
Link: https://groups.google.com/g/clang-built-linux/c/mPQb9_ZWW0s/m/W7o6S-QTBAAJ
Link: https://github.com/ClangBuiltLinux/misc-scripts


Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
Reviewed-by: default avatarMiguel Ojeda <ojeda@kernel.org>
Reviewed-by: default avatarMark Brown <broonie@kernel.org>
Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      df05c0e9
    • Łukasz Stelmach's avatar
      streamline_config.pl: show the full Kconfig name · 0431acd8
      Łukasz Stelmach authored 
      
Show the very same file name that was passed to open()
in case the operation failed.

Signed-off-by: default avatarŁukasz Stelmach <l.stelmach@samsung.com>
      0431acd8
    • Josh Triplett's avatar
      kconfig: Add `make mod2noconfig` to disable module options · c39afe62
      Josh Triplett authored 
      
When converting a modular kernel to a monolithic kernel, once the kernel
works without loading any modules, this helps to quickly disable all the
modules before turning off module support entirely.

Refactor conf_rewrite_mod_or_yes to a more general
conf_rewrite_tristates that accepts an old and new state.

Signed-off-by: default avatarJosh Triplett <josh@joshtriplett.org>
Tested-by: default avatarBjörn Töpel <bjorn@kernel.org>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      c39afe62
  33. Nov 26, 2021
  35. Nov 10, 2021

Open hardware computers for makers, educators and professionals