Presumably, arch/{parisc,s390,sh}/boot/compressed/Makefile copied
arch/x86/boot/compressed/Makefile, but vmlinux.bin.all-y is useless
here because it is the same as $(obj)/vmlinux.bin.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

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 updated the following Makefiles
accordingly:

  arch/arm/boot/compressed/Makefile
  arch/h8300/boot/compressed/Makefile
  arch/mips/boot/compressed/Makefile
  arch/parisc/boot/compressed/Makefile
  arch/s390/boot/compressed/Makefile
  arch/sh/boot/compressed/Makefile
  arch/x86/boot/compressed/Makefile

I reused the current macro names for the normal usecases; they produce
the compressed data in the proper format.

I did not touch the following:

  arch/arc/boot/Makefile
  arch/arm64/boot/Makefile
  arch/csky/boot/Makefile
  arch/mips/boot/Makefile
  arch/riscv/boot/Makefile
  arch/sh/boot/Makefile
  kernel/Makefile

This means those Makefiles will stop appending the size data.

I dropped the 'override size_append' hack from usr/Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

'export suffix-y' does not work reliably because hyphens are disallowed
in shell variables.

A similar issue was fixed by commit 2bfbe788 ("kbuild: Do not use
hyphen in exported variable name").

If I do similar in dash, ARCH=sh fails to build.

  $ mv linux linux~
  $ cd linux~
  $ dash
  $ make O=foo/bar ARCH=sh CROSS_COMPILE=sh4-linux-gnu- defconfig all
  make[1]: Entering directory '/home/masahiro/linux~/foo/bar'
    [ snip ]
  make[4]: *** No rule to make target 'arch/sh/boot/compressed/vmlinux.bin.', needed by 'arch/sh/boot/compressed/piggy.o'.  Stop.
  make[3]: *** [/home/masahiro/linux~/arch/sh/boot/Makefile:40: arch/sh/boot/compressed/vmlinux] Error 2
  make[2]: *** [/home/masahiro/linux~/arch/sh/Makefile:194: zImage] Error 2
  make[1]: *** [/home/masahiro/linux~/Makefile:350: __build_one_by_one] Error 2
  make[1]: Leaving directory '/home/masahiro/linux~/foo/bar'
  make: *** [Makefile:219: __sub-make] Error 2

The maintainer of GNU Make stated that there is no consistent way to
export variables that do not meet the shell's naming criteria.
(https://savannah.gnu.org/bugs/?55719)

Consequently, you cannot use hyphens in exported variables.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

`BAZ` takes `FOO`'s value as default (as far as `BAR` allows it).
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Use built-in functions instead of shell commands to avoid forking
processes.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

extract-cert is only used in certs/Makefile.

Move it there and build extract-cert on demand.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

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: Masahiro Yamada <masahiroy@kernel.org>

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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

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: Masahiro Yamada <masahiroy@kernel.org>

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: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

This dependency is necessary irrespective of the mentioned GCC PR
because the embedded certificates are build artifacts and must be
generated by extract_certs before *.S files are compiled.

The comment sounds like we are hoping to remove these dependencies
someday. No, we cannot remove them.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

'make clean' removes files listed in 'targets'. It is redundant to
specify both 'targets' and 'clean-files'.

Move 'targets' assignments out of the ifeq-conditionals so
scripts/Makefile.clean can see them.

One effective change is that certs/certs/signing_key.x509 is now
deleted by 'make clean' instead of 'make mrproper. This certificate
is embedded in the kernel. It is not used in any way by external
module builds.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

The .incbin directive in certs/system_certificates.S includes
certs/signing_key.x509 and certs/x509_certificate_list, both of which
are generated by extract_certs, i.e. exist in $(objtree).

This option -I$(srctree) is unneeded.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

cmd_extract_certs is defined twice. Unify them.

The current log shows the input file $(2), which might be empty.
You cannot know what is being created from the log, "EXTRACT_CERTS".

Change the log to show the output file with better alignment.

[Before]

  EXTRACT_CERTS   certs/signing_key.pem
  CC      certs/system_keyring.o
  EXTRACT_CERTS
  AS      certs/system_certificates.o
  CC      certs/common.o
  CC      certs/blacklist.o
  EXTRACT_CERTS
  AS      certs/revocation_certificates.o

[After]

  CERT    certs/signing_key.x509
  CC      certs/system_keyring.o
  CERT    certs/x509_certificate_list
  AS      certs/system_certificates.o
  CC      certs/common.o
  CC      certs/blacklist.o
  CERT    certs/x509_revocation_list
  AS      certs/revocation_certificates.o
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Do not repeat $(obj)/x509.genkey or $(obj)/signing_key.pem
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Linux 5.15 is out. Remove this stub now.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

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: Masahiro Yamada <masahiroy@kernel.org>

If the key type of the existing signing key does not match to
CONFIG_MODULE_SIG_KEY_TYPE_*, the Makefile removes it so that it is
re-generated.

Use if_changed so that the key is re-generated when the key type is
changed (that is, the openssl command line is changed).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Commit 5d06ee20 ("modsign: hide openssl output in silent builds")
silenced the key generation log from openssl in silent builds.

Since commit 174a1dcc ("kbuild: sink stdout from cmd for silent
build"), the 'cmd' macro can handle it in a cleaner way.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When you run Kbuild with the parallel option -j, the messages from this
rule and others are interleaved, like follows:

    ###
      CC      arch/x86/mm/pat/set_memory.o
    ### Now generating an X.509 key pair to be used for signing modules.
    ###
    ### If this takes a long time, you might wish to run rngd in the
    ### background to keep the supply of entropy topped up.  It
      CC      arch/x86/events/intel/bts.o
      HDRTEST usr/include/linux/qnx4_fs.h
      CC      arch/x86/events/zhaoxin/core.o
    ### needs to be run as root, and uses a hardware random
    ### number generator if one is available.
      AR      init/built-in.a
    ###

On modern machines, it does not take a long time to generate the key.

Remove the ugly log messages.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When x509.genkey is created, it prints a log:

  Generating X.509 key generation config

..., which is not the ordinary Kbuild log style.

Check-in the default config as certs/default_x509.genkey to make it
readable, and copy it to certs/x509.genkey if it is not present.

The log is shown in the Kbuild style.

  COPY    certs/x509.genkey
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

CONFIG_MODULE_SIG_HASH is defined by init/Kconfig. This $(error ...) is
never reachable. (If it is, you need to fix the bug.)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This is not used or exported.

BUILTIN_DTB is locally defined and used in arch/nds32/boot/dts/Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When the condition "MODULE_SIG || (IMA_APPRAISE_MODSIG && MODULES)"
is unmet, you cannot choose anything in the choice, but the choice
menu is still displayed in the menuconfig etc.

Move the 'depends on' to the choice to hide the meaningless menu.

Also delete the redundant 'default'. In a choice, the first entry is
the default.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The minimum supported version of LLVM has been raised to 11.0.0, meaning
this check is always true, so it can be dropped.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The minimum supported version of LLVM has been raised to 11.0.0, meaning
this check is always true, so it can be dropped.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This reverts commit 7411cfc3.

The minimum supported version of LLVM has been raised to 11.0.0, meaning
this check is always true, so it can be dropped.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The minimum supported version of LLVM has been raised to 11.0.0, meaning
this check is always true, so it can be dropped.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The minimum supported version of LLVM has been raised to 11.0.0, meaning
this check is always true, so it can be dropped.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

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-scriptsSigned-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Show the very same file name that was passed to open()
in case the operation failed.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

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: Josh Triplett <josh@joshtriplett.org>
Tested-by: Björn Töpel <bjorn@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Pull vhost,virtio,vdpa bugfixes from Michael Tsirkin:
 "Misc fixes all over the place.

  Revert of virtio used length validation series: the approach taken
  does not seem to work, breaking too many guests in the process. We'll
  need to do length validation using some other approach"

[ This merge also ends up reverting commit f7a36b03 ("vsock/virtio:
  suppress used length validation"), which came in through the
  networking tree in the meantime, and was part of that whole used
  length validation series   - Linus ]

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  vdpa_sim: avoid putting an uninitialized iova_domain
  vhost-vdpa: clean irqs before reseting vdpa device
  virtio-blk: modify the value type of num in virtio_queue_rq()
  vhost/vsock: cleanup removing `len` variable
  vhost/vsock: fix incorrect used length reported to the guest
  Revert "virtio_ring: validate used buffer length"
  Revert "virtio-net: don't let virtio core to validate used length"
  Revert "virtio-blk: don't let virtio core to validate used length"
  Revert "virtio-scsi: don't let virtio core to validate used buffer length"

Pull x86 build fix from Thomas Gleixner:
 "A single fix for a missing __init annotation of prepare_command_line()"

* tag 'x86-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot: Mark prepare_command_line() __init

Pull scheduler fix from Thomas Gleixner:
 "A single scheduler fix to ensure that there is no stale KASAN shadow
  state left on the idle task's stack when a CPU is brought up after it
  was brought down before"

* tag 'sched-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/scs: Reset task stack state in bringup_cpu()

Pull perf fix from Thomas Gleixner:
 "A single fix for perf to prevent it from sending SIGTRAP to another
  task from a trace point event as it's not possible to deliver a
  synchronous signal to a different task from there"

* tag 'perf-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf: Ignore sigtrap for tracepoints destined for other tasks

Pull locking fixes from Thomas Gleixner:
 "Two regression fixes for reader writer semaphores:

   - Plug a race in the lock handoff which is caused by inconsistency of
     the reader and writer path and can lead to corruption of the
     underlying counter.

   - down_read_trylock() is suboptimal when the lock is contended and
     multiple readers trylock concurrently. That's due to the initial
     value being read non-atomically which results in at least two
     compare exchange loops. Making the initial readout atomic reduces
     this significantly. Whith 40 readers by 11% in a benchmark which
     enforces contention on mmap_sem"

* tag 'locking-urgent-2021-11-28' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/rwsem: Optimize down_read_trylock() under highly contended case
  locking/rwsem: Make handoff bit handling more consistent

Pull another tracing fix from Steven Rostedt:
 "Fix the fix of pid filtering

  The setting of the pid filtering flag tested the "trace only this pid"
  case twice, and ignored the "trace everything but this pid" case.

  The 5.15 kernel does things a little differently due to the new sparse
  pid mask introduced in 5.16, and as the bug was discovered running the
  5.15 kernel, and the first fix was initially done for that kernel,
  that fix handled both cases (only pid and all but pid), but the
  forward port to 5.16 created this bug"

* tag 'trace-v5.16-rc2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Test the 'Do not trace this pid' case in create event