| Age | Commit message (Collapse) | Author |
|---|
|
Due to kernel commit 41ef3c1a6bb0 ("pinctrl: Don't allow PINCTRL_AMD to
be a module"), driver PINCTRL_AMD can only be built as built-in driver
or disabled.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/3 [
Author: Khem Raj
Email: raj.khem@gmail.com
Subject: perf python: Account for multiple words in CC
Date: Sun, 4 Dec 2022 18:06:52 -0800
Sometimes build systems may append options e.g. --sysroot etc. to CC
variable especially in cross-compile environments like yocto project
where CC varable is composed of cross-compiler name and some needed
options for it to work in a relocatable environment. Therefore separate
out the compiler name from rest of the options in CC, then add the
options via second argument to Popen() API
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Fangrui Song <maskray@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: John Keeping <john@metanate.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/3 [
Author: Khem Raj
Email: raj.khem@gmail.com
Subject: libbpf: Fix build warning on ref_ctr_off
Date: Sun, 4 Dec 2022 18:23:47 -0800
Clang warns on 32-bit ARM on this comparision
libbpf.c:10497:18: error: result of comparison of constant 4294967296 with expression of type 'size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (ref_ctr_off >= (1ULL << PERF_UPROBE_REF_CTR_OFFSET_BITS))
~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check for platform long int to be larger than 32-bits before enabling
this check, it false on 32bit anyways.
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Song Liu <song@kernel.org>
Cc: Yonghong Song <yhs@fb.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
3/3 [
Author: Khem Raj
Email: raj.khem@gmail.com
Subject: tools: Remove some options from CLANG_CROSS_FLAGS
Date: Sun, 4 Dec 2022 18:33:48 -0800
These options are not needed with OE/Yocto since compiler is already
passing these options via TOOLCHAIN_OPTIONS, having these options infact
regressed OE builds because build time --sysroot on OE cross compiler is
/not/exist and that creates problems where clang can no more find system
headers anymore during compilation
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The kernel now has a new testing module: gpio-sim. It's meant to replace
gpio-mockup and will be used by ptest in the yocto recipe for libgpiod v2.
Add a kernel feature to support it.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
[NOTE]: 'CONFIG_CRYPTO_CCM' last val (m) and .config val (y) do not match
[INFO]: raw config text:
config CRYPTO_CCM
tristate "CCM support"
select CRYPTO_CTR
select CRYPTO_HASH
select CRYPTO_AEAD
select CRYPTO_MANAGER
depends on CRYPTO
help
Support for Counter with CBC MAC. Required for IPsec.
Config 'CRYPTO_CCM' has the following Direct dependencies (CRYPTO_CCM=y):
CRYPTO(=y)
Parent dependencies are:
CRYPTO [y]
[INFO]: selection details for 'CONFIG_CRYPTO_CCM':
Symbols currently y-selecting this symbol:
- CIFS
Symbols currently m-selecting this symbol:
- MAC80211
Symbols currently n-selecting this symbol (no effect):
- MAC802154
- LIB80211_CRYPT_CCMP
- RTL8192U
- RTLLIB_CRYPTO_CCMP
- SMB_SERVER
- CRYPTO_DEV_PPC4XX
- CRYPTO_DEV_NX_ENCRYPT
[NOTE]: 'CONFIG_CRYPTO_GCM' last val (m) and .config val (y) do not match
[INFO]: raw config text:
config CRYPTO_GCM
tristate "GCM/GMAC support"
select CRYPTO_CTR
select CRYPTO_AEAD
select CRYPTO_GHASH
select CRYPTO_NULL
select CRYPTO_MANAGER
depends on CRYPTO
help
Support for Galois/Counter Mode (GCM) and Galois Message
Authentication Code (GMAC). Required for IPSec.
Config 'CRYPTO_GCM' has the following Direct dependencies (CRYPTO_GCM=y):
CRYPTO(=y)
Parent dependencies are:
CRYPTO [y]
[INFO]: selection details for 'CONFIG_CRYPTO_GCM':
Symbols currently y-selecting this symbol:
- XFRM_ESP
- CIFS
Symbols currently m-selecting this symbol:
- TIPC_CRYPTO
- MAC80211
Symbols currently n-selecting this symbol (no effect):
- TLS
- CEPH_LIB
- MACSEC
- SMB_SERVER
- CRYPTO_DEV_PPC4XX
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
[INFO]: the following symbols were not found in the active configuration:
- CONFIG_HARDENED_USERCOPY_FALLBACK
- CONFIG_LEGACY_VSYSCALL_EMULATE
Ref:
https://github.com/torvalds/linux/commit/bf00745e7791fe2ba7941aeead8528075a158bbe
https://github.com/torvalds/linux/commit/53944f171a89dff4e2a3d76f42e6eedb551bb861
Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@windriver.com
Subject: check console device file on fs when booting
Date: Thu, 8 Apr 2010 23:44:21 -0700
If a root filesystem is generated as non-root, one of
the tell tale signs is /dev/console not being a character
file. To save a whole class of questions, let's just test
for the condition and let the user know.
vfs_lstat() which was used previously would fail with certain
configurations. This was likely due to the involved functions being
marked __init at some point in the past.
Signed-off-by: Richard Laroque <rlarocqu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The config has been renamed:
https://github.com/torvalds/linux/commit/8b766b0f8eece55155146f7628610ce54a065e0f
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
CONFIG_RADIO_ADAPTERS is now a tristate [1] which leads to problems
like:
[2022-11-02T14:02:07.754Z] [NOTE]: 'CONFIG_RADIO_ADAPTERS' last val (y) and .config val (m) do not match
[2022-11-02T14:02:07.754Z] [INFO]: CONFIG_RADIO_ADAPTERS : m ## .config: 4072 :configs/v5.19/standard/preempt-rt/features/media/media-radio.cfg (y)
[2022-11-02T14:02:07.754Z] [INFO]: raw config text:
[2022-11-02T14:02:07.754Z]
[2022-11-02T14:02:07.754Z] menuconfig RADIO_ADAPTERS
[2022-11-02T14:02:07.754Z] tristate "Radio Adapters"
[2022-11-02T14:02:07.754Z] default VIDEO_DEV
[2022-11-02T14:02:07.754Z] depends on VIDEO_DEV && MEDIA_RADIO_SUPPORT && MEDIA_SUPPORT
[2022-11-02T14:02:07.754Z] help
[2022-11-02T14:02:07.754Z] Say Y here to enable selecting AM/FM radio adapters.
[2022-11-02T14:02:07.754Z]
[2022-11-02T14:02:07.754Z] Config 'RADIO_ADAPTERS' has the following Direct dependencies (RADIO_ADAPTERS=m):
[2022-11-02T14:02:07.754Z] VIDEO_DEV(=m) && MEDIA_RADIO_SUPPORT(=y) && MEDIA_SUPPORT(=m)
[2022-11-02T14:02:07.754Z] Parent dependencies are:
[2022-11-02T14:02:07.754Z] MEDIA_RADIO_SUPPORT [y] VIDEO_DEV [m] MEDIA_SUPPORT [m]
[2022-11-02T14:02:07.754Z]
[2022-11-02T14:02:07.754Z] [INFO]: selection details for 'CONFIG_RADIO_ADAPTERS':
[2022-11-02T14:02:07.754Z] Symbols currently m-selecting this symbol:
[2022-11-02T14:02:07.754Z] - VIDEO_BT848
[2022-11-02T14:02:07.754Z]
[2022-11-02T14:02:07.754Z] Symbols currently n-selecting this symbol (no effect):
[2022-11-02T14:02:07.754Z] - SND_ES1968_RADIO
[2022-11-02T14:02:07.754Z] - SND_FM801_TEA575X_BOOL
[2022-11-02T14:02:07.754Z]
[1] https://github.com/torvalds/linux/commit/215d49a41709610b9e82a49b27269cfaff1ef0b6
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Teoh Jay Shen <jay.shen.teoh@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Teoh Jay Shen <jay.shen.teoh@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit d334505d98a85ffe7549026d10e43cccd897e19c [efi.cfg: Drop ACPI dependency]
is generating configuration warnings on both qemuarm64 and x86 for the
poky-tiny configuration.
x864:
- because we configure tiny with allnoconfig, and then apply our
fragments, the default of ACPI=y for x86 doesn't hold. We need
to exlicitly enable it. We put it in the x86 fragment, to avoid
bringing warnings back for arm32
ARM:
- We can't assign to ARCH_SUPPORTS_ACPI, as that is a select only
value. The only selector for that config in arch/arm is CONFIG_EFI.
The default of CONFIG_ACPI was added to support EFI if required,
but since CONFIG_EFI takes care of the selection, we don't need it
in our BSP configuration.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Starting with 5.17, NFT_COUNTER became built-in:
023223dfbfb3 netfilter: nf_tables: make counter support built-in
The warning seen with 5.19 is:
[kernel config]: This BSP contains fragments with warnings:
[INFO]: the following symbols were not found in the active configuration:
- CONFIG_NFT_COUNTER
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Remove intel-x86-hugepage.cfg.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Remove amd-x86-hugepage.cfg.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Currently, only 64-bit is supported.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
On X86 this will have no impact as CONFIG_ACPI is enabled by default. On
the other hand, ARM64 would be affected as they don't have the same
default. The defconfig for arm64 recommends CONFIG_ACPI and this patch
follows this recommendation in the qemuarm64 bsp configuration to fix
ACPI-only EFI boots on this arch.
arm (32bit) would also be unaffected as there is no ACPI support there
at all. And this unconditional drop (CONFIG_ACPI) will actually fix a
configuration warning when enabling EFI on a arm (32bit) machine:
[INFO]: config 'CONFIG_ACPI' was set, but it wasn't assignable, check
(parent) dependencies
Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Due to the following kernel commits:
04e8d9d139c9 ("ARM: omap: split up arch/arm/plat-omap/Kconfig")
d379e8899a8d ("ARM: omap1: move 32k counter from plat-omap to mach-omap1")
The OMAP_32K_TIMER and OMAP_RESET_CLOCKS are protected by ARCH_OMAP1 now.
Since we don't enable the ARCH_OMAP1 for the beaglebone, we would get
two kernel config mismatch warnings. Given these two options have
nothing to do with the beaglebone board, drop them to suppress the
warnings.
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Add an nft_test.scc file, which includes both nf_tables.cfg and a newly
added nft_test.cfg file.
The nft_test.scc file include nftables.scc and also enables more nftables features.
Previously 26/310 of the nftables ptests failed, due to missing kernel modules.
It's impossible to know which nftables features will be used so add more configs
in a new scc file to ensure that most nftables features used by nft work.
The added features are:
NF_CONNTRACK_TIMEOUT
enables support for connection tracking timeout extension.
This allows you to attach timeout policies to flow via the CT target.
NFT_FLOW_OFFLOAD
adds the "flow_offload" expression that you can use to choose what flows
are placed into the hardware.
NF_FLOW_TABLE
adds the flow table core infrastructure.
NF_FLOW_TABLE_INET
adds the flow table mixed IPv4/IPv6 support.
NFT_NUMGEN
adds the number generator expression used to perform incremental
counting and random numbers bound to a upper limit.
NFT_OSF
allows matching packets from an specific OS.
NFT_QUOTA
adds the "quota" expression that you can use to match enforce bytes quotas.
NFT_SYNPROXY
The SYNPROXY expression allows you to intercept TCP connections and
establish them using syncookies before they are passed on to the
server. This allows to avoid conntrack and server resource usage
during SYN-flood attacks.
NFT_XFRM
adds an expression that you can use to extract properties of a packets
security association.
This brings the nftables-1.0.4 ptest results with 5.19.x from:
[OK] 283 [FAILED] 26 [TOTAL] 310
to:
[OK] 310 [FAILED] 0 [TOTAL] 310
Signed-off-by: Aryaman Gupta <Aryaman.Gupta@windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 83a44a4f47ad20997aebb311fc678a13cde391d7
Author: Masahiro Yamada <masahiroy@kernel.org>
Date: Mon Mar 14 12:48:41 2022 -0700
x86: Remove toolchain check for X32 ABI capability
Commit 0bf6276392e9 ("x32: Warn and disable rather than error if
binutils too old") added a small test in arch/x86/Makefile because
binutils 2.22 or newer is needed to properly support elf32-x86-64. This
check is no longer necessary, as the minimum supported version of
binutils is 2.23, which is enforced at configuration time with
scripts/min-tool-version.sh.
Remove this check and replace all uses of CONFIG_X86_X32 with
CONFIG_X86_X32_ABI, as two symbols are no longer necessary.
[nathan: Rebase, fix up a few places where CONFIG_X86_X32 was still
used, and simplify commit message to satisfy -tip requirements]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20220314194842.3452-2-nathan@kernel.org
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 5f9a62ff7d2808c7b56c0ec90f3b7eae5872afe6
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Sun Feb 6 12:25:47 2022 -0500
NFSD: Remove CONFIG_NFSD_V3
Eventually support for NFSv2 in the Linux NFS server is to be
deprecated and then removed.
However, NFSv2 is the "always supported" version that is available
as soon as CONFIG_NFSD is set. Before NFSv2 support can be removed,
we need to choose a different "always supported" version.
This patch removes CONFIG_NFSD_V3 so that NFSv3 is always supported,
as NFSv2 is today. When NFSv2 support is removed, NFSv3 will become
the only "always supported" NFS version.
The defconfigs still need to be updated to remove CONFIG_NFSD_V3=y.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 9958d30f38b96fb763a10d44d18ddad39127d5f4
Author: Mauro Carvalho Chehab <mchehab@kernel.org>
Date: Sun Mar 13 07:25:46 2022 +0100
media: Kconfig: cleanup VIDEO_DEV dependencies
media Kconfig has two entries associated to V4L API:
VIDEO_DEV and VIDEO_V4L2.
On Kernel 2.6.x, there were two V4L APIs, each one with its own flag.
VIDEO_DEV were meant to:
1) enable Video4Linux and make its Kconfig options to appear;
2) it makes the Kernel build the V4L core.
while VIDEO_V4L2 where used to distinguish between drivers that
implement the newer API and drivers that implemented the former one.
With time, such meaning changed, specially after the removal of
all V4L version 1 drivers.
At the current implementation, VIDEO_DEV only does (1): it enables
the media options related to V4L, that now has:
menu "Video4Linux options"
visible if VIDEO_DEV
source "drivers/media/v4l2-core/Kconfig"
endmenu
but it doesn't affect anymore the V4L core drivers.
The rationale is that the V4L2 core has a "soft" dependency
at the I2C bus, and now requires to select a number of other
Kconfig options:
config VIDEO_V4L2
tristate
depends on (I2C || I2C=n) && VIDEO_DEV
select RATIONAL
select VIDEOBUF2_V4L2 if VIDEOBUF2_CORE
default (I2C || I2C=n) && VIDEO_DEV
In the past, merging them would be tricky, but it seems that it is now
possible to merge those symbols, in order to simplify V4L dependencies.
Let's keep VIDEO_DEV, as this one is used on some make *defconfig
configurations.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> # for meson-vdec & meson-ge2d
Acked-by: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
Acked-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 47e9624616c80c9879feda536c48c6a3a0ed9835
Author: Christoph Hellwig <hch@lst.de>
Date: Tue Oct 19 09:56:39 2021 +0200
block: remove support for cryptoloop and the xor transfer
Support for cyrptoloop has been officially marked broken and deprecated
in favor of dm-crypt (which supports the same broken algorithms if
needed) in Linux 2.6.4 (released in March 2004), and support for it has
been entirely removed from losetup in util-linux 2.23 (released in April
2013). The XOR transfer has never been more than a toy to demonstrate
the transfer in the bad old times of crypto export restrictions.
Remove them as they have some nasty interactions with loop device life
times due to the iteration over all loop devices in
loop_unregister_transfer.
Suggested-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20211019075639.2333969-1-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: arch/*: Disable softirq stacks on PREEMPT_RT.
Date: Tue, 14 Jun 2022 20:18:14 +0200
PREEMPT_RT preempts softirqs and the current implementation avoids
do_softirq_own_stack() and only uses __do_softirq().
Disable the unused softirqs stacks on PREEMPT_RT to save some memory and
ensure that do_softirq_own_stack() is not used bwcause it is not expected.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/CAK8P3a1QmeAscV-Ory-Dae4RoLvDSPEjEgFGQHR9U8jUervGuA@mail.gmail.com
]
2/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: blk-mq: Don't disable preemption around __blk_mq_run_hw_queue().
Date: Wed, 22 Jun 2022 09:42:37 +0200
__blk_mq_delay_run_hw_queue() disables preemption to get a stable
current CPU number and then invokes __blk_mq_run_hw_queue() if the CPU
number is part the mask.
__blk_mq_run_hw_queue() acquires a spin_lock_t which is a sleeping lock
on PREEMPT_RT and can't be acquired with disabled preemption.
It is not required for correctness to invoke __blk_mq_run_hw_queue() on
a CPU matching hctx->cpumask. Both (async and direct requests) can run
on a CPU not matching hctx->cpumask.
The CPU mask without disabling preemption and invoking
__blk_mq_run_hw_queue().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/YrLSEiNvagKJaDs5@linutronix.de
Reviewed-by: Ming Lei <ming.lei@redhat.com>
]
3/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: genirq: Provide generic_handle_domain_irq_safe().
Date: Mon, 9 May 2022 16:04:08 +0200
Provide generic_handle_domain_irq_safe() which can used from any context.
This similar to commit
509853f9e1e7b ("genirq: Provide generic_handle_irq_safe()")
but this time for the irq-domains interface. It has been reported for
the amd-pinctrl driver via bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=215954
I looked around and added a few users so it is not just one user API :)
Instead of generic_handle_irq(irq_find_mapping)) one can use
generic_handle_domain_irq().
The problem with generic_handle_domain_irq() is that with `threadirqs'
it will trigger "WARN_ON_ONCE(!in_hardirq())". That interrupt handler
can't be marked non-threaded because it is a shared handler (it is
marked as such and I can't tell the interrupt can be really shared on
the system).
Ignoring the just mentioned warning, on PREEMPT_RT the threaded handler
is invoked with enabled interrupts leading other problems.
Do we do this?
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/YnkfWFzvusFFktSt@linutronix.de
]
4/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: printk: Skip console drivers on PREEMPT_RT.
Date: Wed, 20 Jul 2022 10:04:29 +0200
printk might be invoked in a context with disabled interrupts and or
preemption and additionally disables interrupts before it invokes the
console drivers. This behaviour is not desired on PREEMPT_RT:
- The console driver are using spinlock_t based locking which become sleeping
locks on PREEMPT_RT and must not be acquired with disabled interrupts (or
preemption).
- The locks within the console drivers must remain sleeping locks and they must
not disable interrupts. Printing (and polling for its completion) at 115200
baud on an UART takes too long for PREEMPT_RT in general and so raises the
latency of the IRQ-off time of the system beyond acceptable levels.
Skip printing to the console as temporary workaround until the printing threads
and atomic consoles have been introduced or another solution which is
compatible with the PREEMPT_RT approach.
With this change, the user will not see any kernel message printed to the
console but can retrieve the printk buffer from userland (via the dmesg
command). This allows enable PREEMPT_RT as a whole without disabling printk and
loosing all kernel output.
Disable console printing on PREEMPT_RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/Yt6zwP9xSdUhsoQ9@linutronix.de
]
5/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: lib/vsprintf: Remove static_branch_likely() from __ptr_to_hashval().
Date: Fri, 29 Jul 2022 15:52:45 +0200
Using static_branch_likely() to signal that ptr_key has been filled is a
bit much given that it is not a fast path.
Replace static_branch_likely() with bool for condition and a memory
barrier for ptr_key.
Suggested-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220729154716.429964-2-bigeasy@linutronix.de
]
6/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: lib/vsprintf: Initialize vsprintf's pointer hash once the random core is ready.
Date: Fri, 29 Jul 2022 10:53:00 +0200
The printk code invokes vnsprintf in order to compute the complete
string before adding it into its buffer. This happens in an IRQ-off
region which leads to a warning on PREEMPT_RT in the random code if the
format strings contains a %p for pointer printing. This happens because
the random core acquires locks which become sleeping locks on PREEMPT_RT
which must not be acquired with disabled interrupts and or preemption
disabled.
By default the pointers are hashed which requires a random value on the
first invocation (either by printk or another user which comes first.
One could argue that there is no need for printk to disable interrupts
during the vsprintf() invocation which would fix the just mentioned
problem. However printk itself can be invoked in a context with
disabled interrupts which would lead to the very same problem.
Move the initializaion of ptr_key into a worker and schedule it from
subsys_initcall(). This happens early but after the workqueue subsystem
is ready. Use get_random_bytes_wait() to retrieve the random value which
will block until random data is available.
Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220729154716.429964-3-bigeasy@linutronix.de
]
7/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: signal: Don't disable preemption in ptrace_stop() on PREEMPT_RT.
Date: Wed, 22 Jun 2022 11:36:17 +0200
Commit
53da1d9456fe7 ("fix ptrace slowness")
is just band aid around the problem.
The invocation of do_notify_parent_cldstop() wakes the parent and makes
it runnable. The scheduler then wants to replace this still running task
with the parent. With the read_lock() acquired this is not possible
because preemption is disabled and so this is deferred until read_unlock().
This scheduling point is undesired and is avoided by disabling preemption
around the unlock operation enabled again before the schedule() invocation
without a preemption point.
This is only undesired because the parent sleeps a cycle in
wait_task_inactive() until the traced task leaves the run-queue in
schedule(). It is not a correctness issue, it is just band aid to avoid the
visbile delay which sums up over multiple invocations.
The task can still be preempted if an interrupt occurs between
preempt_enable_no_resched() and freezable_schedule() because on the IRQ-exit
path of the interrupt scheduling _will_ happen. This is ignored since it does
not happen very often.
On PREEMPT_RT keeping preemption disabled during the invocation of
cgroup_enter_frozen() becomes a problem because the function acquires
css_set_lock which is a sleeping lock on PREEMPT_RT and must not be
acquired with disabled preemption.
Don't disable preemption on PREEMPT_RT. Remove the TODO regarding adding
read_unlock_no_resched() as there is no need for it and will cause harm.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220720154435.232749-2-bigeasy@linutronix.de
]
8/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: sched: Consider task_struct::saved_state in wait_task_inactive().
Date: Wed, 22 Jun 2022 12:27:05 +0200
Ptrace is using wait_task_inactive() to wait for the tracee to reach a
certain task state. On PREEMPT_RT that state may be stored in
task_struct::saved_state while the tracee blocks on a sleeping lock and
task_struct::__state is set to TASK_RTLOCK_WAIT.
It is not possible to check only for TASK_RTLOCK_WAIT to be sure that the task
is blocked on a sleeping lock because during wake up (after the sleeping lock
has been acquired) the task state is set TASK_RUNNING. After the task in on CPU
and acquired the pi_lock it will reset the state accordingly but until then
TASK_RUNNING will be observed (with the desired state saved in saved_state).
Check also for task_struct::saved_state if the desired match was not found in
task_struct::__state on PREEMPT_RT. If the state was found in saved_state, wait
until the task is idle and state is visible in task_struct::__state.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Valentin Schneider <vschneid@redhat.com>
Link: https://lkml.kernel.org/r/Yt%2FpQAFQ1xKNK0RY@linutronix.de
]
9/55 [
Author: Al Viro
Email: viro@zeniv.linux.org.uk
Subject: fs/dcache: d_add_ci() needs to complete parallel lookup.
Date: Wed, 27 Jul 2022 08:24:15 +0200
Result of d_alloc_parallel() in d_add_ci() is fed to d_splice_alias(), which
*NORMALLY* feeds it to __d_add() or __d_move() in a way that will have
__d_lookup_done() applied to it.
However, there is a nasty possibility - d_splice_alias() might legitimately
fail without having marked the sucker not in-lookup. dentry will get dropped
by d_add_ci(), so ->d_wait won't end up pointing to freed object, but it's
still a bug - retain_dentry() will scream bloody murder upon seeing that, and
for a good reason; we'll get hash chain corrupted. It's impossible to hit
without corrupted fs image (ntfs or case-insensitive xfs), but it's a bug.
Invoke d_lookup_done() after d_splice_alias() to ensure that the
in-lookip flag is always cleared.
Fixes: d9171b9345261 ("parallel lookups machinery, part 4 (and last)")
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
10/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: fs/dcache: Disable preemption on i_dir_seq write side on PREEMPT_RT
Date: Sun, 12 Jun 2022 16:27:28 +0200
i_dir_seq is a sequence counter with a lock which is represented by the
lowest bit. The writer atomically updates the counter which ensures that it
can be modified by only one writer at a time. This requires preemption to
be disabled across the write side critical section.
On !PREEMPT_RT kernels this is implicit by the caller acquiring
dentry::lock. On PREEMPT_RT kernels spin_lock() does not disable preemption
which means that a preempting writer or reader would live lock. It's
therefore required to disable preemption explicitly.
An alternative solution would be to replace i_dir_seq with a seqlock_t for
PREEMPT_RT, but that comes with its own set of problems due to arbitrary
lock nesting. A pure sequence count with an associated spinlock is not
possible because the locks held by the caller are not necessarily related.
As the critical section is small, disabling preemption is a sensible
solution.
Reported-by: Oleg.Karfich@wago.com
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220613140712.77932-2-bigeasy@linutronix.de
]
11/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: fs/dcache: Move the wakeup from __d_lookup_done() to the caller.
Date: Sun, 12 Jun 2022 16:27:29 +0200
__d_lookup_done() wakes waiters on dentry->d_wait. On PREEMPT_RT we are
not allowed to do that with preemption disabled, since the wakeup
acquired wait_queue_head::lock, which is a "sleeping" spinlock on RT.
Calling it under dentry->d_lock is not a problem, since that is also a
"sleeping" spinlock on the same configs. Unfortunately, two of its
callers (__d_add() and __d_move()) are holding more than just ->d_lock
and that needs to be dealt with.
The key observation is that wakeup can be moved to any point before
dropping ->d_lock.
As a first step to solve this, move the wake up outside of the
hlist_bl_lock() held section.
This is safe because:
Waiters get inserted into ->d_wait only after they'd taken ->d_lock
and observed DCACHE_PAR_LOOKUP in flags. As long as they are
woken up (and evicted from the queue) between the moment __d_lookup_done()
has removed DCACHE_PAR_LOOKUP and dropping ->d_lock, we are safe,
since the waitqueue ->d_wait points to won't get destroyed without
having __d_lookup_done(dentry) called (under ->d_lock).
->d_wait is set only by d_alloc_parallel() and only in case when
it returns a freshly allocated in-lookup dentry. Whenever that happens,
we are guaranteed that __d_lookup_done() will be called for resulting
dentry (under ->d_lock) before the wq in question gets destroyed.
With two exceptions wq lives in call frame of the caller of
d_alloc_parallel() and we have an explicit d_lookup_done() on the
resulting in-lookup dentry before we leave that frame.
One of those exceptions is nfs_call_unlink(), where wq is embedded into
(dynamically allocated) struct nfs_unlinkdata. It is destroyed in
nfs_async_unlink_release() after an explicit d_lookup_done() on the
dentry wq went into.
Remaining exception is d_add_ci(). There wq is what we'd found in
->d_wait of d_add_ci() argument. Callers of d_add_ci() are two
instances of ->d_lookup() and they must have been given an in-lookup
dentry. Which means that they'd been called by __lookup_slow() or
lookup_open(), with wq in the call frame of one of those.
Result of d_alloc_parallel() in d_add_ci() is fed to
d_splice_alias(), which either returns non-NULL (and d_add_ci() does
d_lookup_done()) or feeds dentry to __d_add() that will do
__d_lookup_done() under ->d_lock. That concludes the analysis.
Let __d_lookup_unhash():
1) Lock the lookup hash and clear DCACHE_PAR_LOOKUP
2) Unhash the dentry
3) Retrieve and clear dentry::d_wait
4) Unlock the hash and return the retrieved waitqueue head pointer
5) Let the caller handle the wake up.
6) Rename __d_lookup_done() to __d_lookup_unhash_wake() to enforce
build failures for OOT code that used __d_lookup_done() and is not
aware of the new return value.
This does not yet solve the PREEMPT_RT problem completely because
preemption is still disabled due to i_dir_seq being held for write. This
will be addressed in subsequent steps.
An alternative solution would be to switch the waitqueue to a simple
waitqueue, but aside of Linus not being a fan of them, moving the wake up
closer to the place where dentry::lock is unlocked reduces lock contention
time for the woken up waiter.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220613140712.77932-3-bigeasy@linutronix.de
]
12/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: fs/dcache: Move wakeup out of i_seq_dir write held region.
Date: Wed, 27 Jul 2022 11:20:40 +0200
__d_add() and __d_move() wake up waiters on dentry::d_wait from within
the i_seq_dir write held region. This violates the PREEMPT_RT
constraints as the wake up acquires wait_queue_head::lock which is a
"sleeping" spinlock on RT.
There is no requirement to do so. __d_lookup_unhash() has cleared
DCACHE_PAR_LOOKUP and dentry::d_wait and returned the now unreachable wait
queue head pointer to the caller, so the actual wake up can be postponed
until the i_dir_seq write side critical section is left. The only
requirement is that dentry::lock is held across the whole sequence
including the wake up. The previous commit includes an analysis why this
is considered safe.
Move the wake up past end_dir_add() which leaves the i_dir_seq write side
critical section and enables preemption.
For non RT kernels there is no difference because preemption is still
disabled due to dentry::lock being held, but it shortens the time between
wake up and unlocking dentry::lock, which reduces the contention for the
woken up waiter.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
13/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: x86: Allow to enable RT
Date: Wed, 7 Aug 2019 18:15:38 +0200
Allow to select RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
14/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: x86: Enable RT also on 32bit
Date: Thu, 7 Nov 2019 17:49:20 +0100
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
15/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: softirq: Use a dedicated thread for timer wakeups.
Date: Wed, 1 Dec 2021 17:41:09 +0100
A timer/hrtimer softirq is raised in-IRQ context. With threaded
interrupts enabled or on PREEMPT_RT this leads to waking the ksoftirqd
for the processing of the softirq.
Once the ksoftirqd is marked as pending (or is running) it will collect
all raised softirqs. This in turn means that a softirq which would have
been processed at the end of the threaded interrupt, which runs at an
elevated priority, is now moved to ksoftirqd which runs at SCHED_OTHER
priority and competes with every regular task for CPU resources.
This introduces long delays on heavy loaded systems and is not desired
especially if the system is not overloaded by the softirqs.
Split the TIMER_SOFTIRQ and HRTIMER_SOFTIRQ processing into a dedicated
timers thread and let it run at the lowest SCHED_FIFO priority.
RT tasks are are woken up from hardirq context so only timer_list timers
and hrtimers for "regular" tasks are processed here. The higher priority
ensures that wakeups are performed before scheduling SCHED_OTHER tasks.
Using a dedicated variable to store the pending softirq bits values
ensure that the timer are not accidentally picked up by ksoftirqd and
other threaded interrupts.
It shouldn't be picked up by ksoftirqd since it runs at lower priority.
However if the timer bits are ORed while a threaded interrupt is
running, then the timer softirq would be performed at higher priority.
The new timer thread will block on the softirq lock before it starts
softirq work. This "race window" isn't closed because while timer thread
is performing the softirq it can get PI-boosted via the softirq lock by
a random force-threaded thread.
The timer thread can pick up pending softirqs from ksoftirqd but only
if the softirq load is high. It is not be desired that the picked up
softirqs are processed at SCHED_FIFO priority under high softirq load
but this can already happen by a PI-boost by a force-threaded interrupt.
Reported-by: kernel test robot <lkp@intel.com> [ static timer_threads ]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
16/55 [
Author: Frederic Weisbecker
Email: frederic@kernel.org
Subject: rcutorture: Also force sched priority to timersd on boosting test.
Date: Tue, 5 Apr 2022 03:07:51 +0200
ksoftirqd is statically boosted to the priority level right above the
one of rcu_torture_boost() so that timers, which torture readers rely on,
get a chance to run while rcu_torture_boost() is polling.
However timers processing got split from ksoftirqd into their own kthread
(timersd) that isn't boosted. It has the same SCHED_FIFO low prio as
rcu_torture_boost() and therefore timers can't preempt it and may
starve.
The issue can be triggered in practice on v5.17.1-rt17 using:
./kvm.sh --allcpus --configs TREE04 --duration 10m --kconfig "CONFIG_EXPERT=y CONFIG_PREEMPT_RT=y"
Fix this with statically boosting timersd just like is done with
ksoftirqd in commit
ea6d962e80b61 ("rcutorture: Judge RCU priority boosting on grace periods, not callbacks")
Suggested-by: Mel Gorman <mgorman@suse.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://lkml.kernel.org/r/20220405010752.1347437-1-frederic@kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
17/55 [
Author: Frederic Weisbecker
Email: frederic@kernel.org
Subject: tick: Fix timer storm since introduction of timersd
Date: Tue, 5 Apr 2022 03:07:52 +0200
If timers are pending while the tick is reprogrammed on nohz_mode, the
next expiry is not armed to fire now, it is delayed one jiffy forward
instead so as not to raise an inextinguishable timer storm with such
scenario:
1) IRQ triggers and queue a timer
2) ksoftirqd() is woken up
3) IRQ tail: timer is reprogrammed to fire now
4) IRQ exit
5) TIMER interrupt
6) goto 3)
...all that until we finally reach ksoftirqd.
Unfortunately we are checking the wrong softirq vector bitmask since
timersd kthread has split from ksoftirqd. Timers now have their own
vector state field that must be checked separately. As a result, the
old timer storm is back. This shows up early on boot with extremely long
initcalls:
[ 333.004807] initcall dquot_init+0x0/0x111 returned 0 after 323822879 usecs
and the cause is uncovered with the right trace events showing just
10 microseconds between ticks (~100 000 Hz):
|swapper/-1 1dn.h111 60818582us : hrtimer_expire_entry: hrtimer=00000000e0ef0f6b function=tick_sched_timer now=60415486608
|swapper/-1 1dn.h111 60818592us : hrtimer_expire_entry: hrtimer=00000000e0ef0f6b function=tick_sched_timer now=60415496082
|swapper/-1 1dn.h111 60818601us : hrtimer_expire_entry: hrtimer=00000000e0ef0f6b function=tick_sched_timer now=60415505550
Fix this by checking the right timer vector state from the nohz code.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220405010752.1347437-2-frederic@kernel.org
]
18/55 [
Author: Haris Okanovic
Email: haris.okanovic@ni.com
Subject: tpm_tis: fix stall after iowrite*()s
Date: Tue, 15 Aug 2017 15:13:08 -0500
ioread8() operations to TPM MMIO addresses can stall the cpu when
immediately following a sequence of iowrite*()'s to the same region.
For example, cyclitest measures ~400us latency spikes when a non-RT
usermode application communicates with an SPI-based TPM chip (Intel Atom
E3940 system, PREEMPT_RT kernel). The spikes are caused by a
stalling ioread8() operation following a sequence of 30+ iowrite8()s to
the same address. I believe this happens because the write sequence is
buffered (in cpu or somewhere along the bus), and gets flushed on the
first LOAD instruction (ioread*()) that follows.
The enclosed change appears to fix this issue: read the TPM chip's
access register (status code) after every iowrite*() operation to
amortize the cost of flushing data to chip across multiple instructions.
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
19/55 [
Author: Mike Galbraith
Email: umgwanakikbuti@gmail.com
Subject: zram: Replace bit spinlocks with spinlock_t for PREEMPT_RT.
Date: Thu, 31 Mar 2016 04:08:28 +0200
The bit spinlock disables preemption on PREEMPT_RT. With disabled preemption it
is not allowed to acquire other sleeping locks which includes invoking
zs_free().
Use a spinlock_t on PREEMPT_RT for locking and set/ clear ZRAM_LOCK after the
lock has been acquired/ dropped.
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/YqIbMuHCPiQk+Ac2@linutronix.de
]
20/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: iio: adc: stm32-adc: Use generic_handle_domain_irq()
Date: Wed, 11 May 2022 13:06:09 +0200
The call chain
generic_handle_irq(irq_find_mapping(domain, x));
could be replaced with
generic_handle_domain_irq(domain, x);
which looks up the struct irq_desc for the interrupt and handles it with
handle_irq_desc().
This is a slight optimisation given that the driver invokes only one
function and the struct irq_desc is used directly instead being looked
up via irq_to_desc().
Use generic_handle_domain_irq().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/YnuYoQIzJoFIyEJY@linutronix.de
]
21/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/lockdep: Remove lockdep_init_map_crosslock.
Date: Fri, 11 Mar 2022 17:44:57 +0100
The cross-release bits have been removed, lockdep_init_map_crosslock() is
a leftover.
Remove lockdep_init_map_crosslock.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Waiman Long <longman@redhat.com>
Link: https://lore.kernel.org/r/20220311164457.46461-1-bigeasy@linutronix.de
Link: https://lore.kernel.org/r/YqITgY+2aPITu96z@linutronix.de
]
22/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: printk: Bring back the RT bits.
Date: Tue, 19 Jul 2022 20:08:01 +0200
This is a revert of the commits:
| 07a22b61946f0 Revert "printk: add functions to prefer direct printing"
| 5831788afb17b Revert "printk: add kthread console printers"
| 2d9ef940f89e0 Revert "printk: extend console_lock for per-console locking"
| 007eeab7e9f03 Revert "printk: remove @console_locked"
| 05c96b3713aa2 Revert "printk: Block console kthreads when direct printing will be required"
| 20fb0c8272bbb Revert "printk: Wait for the global console lock when the system is going down"
which is needed for the atomic consoles which are used on PREEMPT_RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
23/55 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: add infrastucture for atomic consoles
Date: Fri, 4 Feb 2022 16:01:17 +0106
Many times it is not possible to see the console output on
panic because printing threads cannot be scheduled and/or the
console is already taken and forcibly overtaking/busting the
locks does provide the hoped results.
Introduce a new infrastructure to support "atomic consoles".
A new optional callback in struct console, write_atomic(), is
available for consoles to provide an implemention for writing
console messages. The implementation must be NMI safe if they
can run on an architecture where NMIs exist.
Console drivers implementing the write_atomic() callback must
also select CONFIG_HAVE_ATOMIC_CONSOLE in order to enable the
atomic console code within the printk subsystem.
If atomic consoles are available, panic() will flush the kernel
log only to the atomic consoles (before busting spinlocks).
Afterwards, panic() will continue as before, which includes
attempting to flush the other (non-atomic) consoles.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
24/55 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: serial: 8250: implement write_atomic
Date: Fri, 4 Feb 2022 16:01:17 +0106
Implement a non-sleeping NMI-safe write_atomic() console function in
order to support atomic console printing during a panic.
Trasmitting data requires disabling interrupts. Since write_atomic()
can be called from any context, it may be called while another CPU
is executing in console code. In order to maintain the correct state
of the IER register, use the global cpu_sync to synchronize all
access to the IER register. This synchronization is only necessary
for serial ports that are being used as consoles.
The global cpu_sync is also used to synchronize between the write()
and write_atomic() callbacks. write() synchronizes per character,
write_atomic() synchronizes per line.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
25/55 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: avoid preempt_disable() for PREEMPT_RT
Date: Fri, 4 Feb 2022 16:01:17 +0106
During non-normal operation, printk() calls will attempt to
write the messages directly to the consoles. This involves
using console_trylock() to acquire @console_sem.
Preemption is disabled while directly printing to the consoles
in order to ensure that the printing task is not scheduled away
while holding @console_sem, thus blocking all other printers
and causing delays in printing.
Commit fd5f7cde1b85 ("printk: Never set console_may_schedule in
console_trylock()") specifically reverted a previous attempt at
allowing preemption while printing.
However, on PREEMPT_RT systems, disabling preemption while
printing is not allowed because console drivers typically
acquire a spin lock (which under PREEMPT_RT is an rtmutex).
Since direct printing is only used during early boot and
non-panic dumps, the risks of delayed print output for these
scenarios will be accepted under PREEMPT_RT.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
26/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: Revert "printk: Skip console drivers on PREEMPT_RT."
Date: Wed, 20 Jul 2022 11:31:02 +0200
Revert the previous change and allow printing on consoles now that the atomic
consoles and the printing thread is available.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
27/55 [
Author: Mike Galbraith
Email: umgwanakikbuti@gmail.com
Subject: drm/i915: Use preempt_disable/enable_rt() where recommended
Date: Sat, 27 Feb 2016 08:09:11 +0100
Mario Kleiner suggest in commit
ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms driver.")
a spots where preemption should be disabled on PREEMPT_RT. The
difference is that on PREEMPT_RT the intel_uncore::lock disables neither
preemption nor interrupts and so region remains preemptible.
The area covers only register reads and writes. The part that worries me
is:
- __intel_get_crtc_scanline() the worst case is 100us if no match is
found.
- intel_crtc_scanlines_since_frame_timestamp() not sure how long this
may take in the worst case.
It was in the RT queue for a while and nobody complained.
Disable preemption on PREEPMPT_RT during timestamping.
[bigeasy: patch description.]
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
28/55 [
Author: Mike Galbraith
Email: umgwanakikbuti@gmail.com
Subject: drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates
Date: Sat, 27 Feb 2016 09:01:42 +0100
Commit
8d7849db3eab7 ("drm/i915: Make sprite updates atomic")
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT
because within this section the code attempt to acquire spinlock_t locks which
are sleeping locks on PREEMPT_RT.
According to the comment the interrupts are disabled to avoid random delays and
not required for protection or synchronisation.
If this needs to happen with disabled interrupts on PREEMPT_RT, and the
whole section is restricted to register access then all sleeping locks
need to be acquired before interrupts are disabled and some function
maybe moved after enabling interrupts again.
This includes:
- prepare_to_wait() + finish_wait() due its wake queue.
- drm_crtc_vblank_put() -> vblank_disable_fn() drm_device::vbl_lock.
- skl_pfit_enable(), intel_update_plane(), vlv_atomic_update_fifo() and
maybe others due to intel_uncore::lock
- drm_crtc_arm_vblank_event() due to drm_device::event_lock and
drm_device::vblank_time_lock.
Don't disable interrupts on PREEMPT_RT during atomic updates.
[bigeasy: drop local locks, commit message]
Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
29/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915: Don't check for atomic context on PREEMPT_RT
Date: Mon, 25 Oct 2021 15:05:18 +0200
The !in_atomic() check in _wait_for_atomic() triggers on PREEMPT_RT
because the uncore::lock is a spinlock_t and does not disable
preemption or interrupts.
Changing the uncore:lock to a raw_spinlock_t doubles the worst case
latency on an otherwise idle testbox during testing. Therefore I'm
currently unsure about changing this.
Link: https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
30/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915: Disable tracing points on PREEMPT_RT
Date: Thu, 6 Dec 2018 09:52:20 +0100
Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003
| CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
| Call Trace:
| rt_spin_lock+0x3f/0x50
| gen6_read32+0x45/0x1d0 [i915]
| g4x_get_vblank_counter+0x36/0x40 [i915]
| trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]
The tracing events use trace_i915_pipe_update_start() among other events
use functions acquire spinlock_t locks which are transformed into
sleeping locks on PREEMPT_RT. A few trace points use
intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also
might acquire a sleeping locks on PREEMPT_RT.
At the time the arguments are evaluated within trace point, preemption
is disabled and so the locks must not be acquired on PREEMPT_RT.
Based on this I don't see any other way than disable trace points on
PREMPT_RT.
Reported-by: Luca Abeni <lucabe72@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
31/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE
Date: Wed, 19 Dec 2018 10:47:02 +0100
The order of the header files is important. If this header file is
included after tracepoint.h was included then the NOTRACE here becomes a
nop. Currently this happens for two .c files which use the tracepoitns
behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
32/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915/gt: Queue and wait for the irq_work item.
Date: Wed, 8 Sep 2021 17:18:00 +0200
Disabling interrupts and invoking the irq_work function directly breaks
on PREEMPT_RT.
PREEMPT_RT does not invoke all irq_work from hardirq context because
some of the user have spinlock_t locking in the callback function.
These locks are then turned into a sleeping locks which can not be
acquired with disabled interrupts.
Using irq_work_queue() has the benefit that the irqwork will be invoked
in the regular context. In general there is "no" delay between enqueuing
the callback and its invocation because the interrupt is raised right
away on architectures which support it (which includes x86).
Use irq_work_queue() + irq_work_sync() instead invoking the callback
directly.
Reported-by: Clark Williams <williams@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
]
33/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock()
Date: Wed, 8 Sep 2021 19:03:41 +0200
execlists_dequeue() is invoked from a function which uses
local_irq_disable() to disable interrupts so the spin_lock() behaves
like spin_lock_irq().
This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
the same as spin_lock_irq().
execlists_dequeue_irq() and execlists_dequeue() has each one caller
only. If intel_engine_cs::active::lock is acquired and released with the
_irq suffix then it behaves almost as if execlists_dequeue() would be
invoked with disabled interrupts. The difference is the last part of the
function which is then invoked with enabled interrupts.
I can't tell if this makes a difference. From looking at it, it might
work to move the last unlock at the end of the function as I didn't find
anything that would acquire the lock again.
Reported-by: Clark Williams <williams@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
]
34/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/i915: Drop the irqs_disabled() check
Date: Fri, 1 Oct 2021 20:01:03 +0200
The !irqs_disabled() check triggers on PREEMPT_RT even with
i915_sched_engine::lock acquired. The reason is the lock is transformed
into a sleeping lock on PREEMPT_RT and does not disable interrupts.
There is no need to check for disabled interrupts. The lockdep
annotation below already check if the lock has been acquired by the
caller and will yell if the interrupts are not disabled.
Remove the !irqs_disabled() check.
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
35/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: Revert "drm/i915: Depend on !PREEMPT_RT."
Date: Mon, 21 Feb 2022 17:59:14 +0100
Once the known issues are addressed, it should be safe to enable the
driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
36/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: sched: Add support for lazy preemption
Date: Fri, 26 Oct 2012 18:50:54 +0100
It has become an obsession to mitigate the determinism vs. throughput
loss of RT. Looking at the mainline semantics of preemption points
gives a hint why RT sucks throughput wise for ordinary SCHED_OTHER
tasks. One major issue is the wakeup of tasks which are right away
preempting the waking task while the waking task holds a lock on which
the woken task will block right after having preempted the wakee. In
mainline this is prevented due to the implicit preemption disable of
spin/rw_lock held regions. On RT this is not possible due to the fully
preemptible nature of sleeping spinlocks.
Though for a SCHED_OTHER task preempting another SCHED_OTHER task this
is really not a correctness issue. RT folks are concerned about
SCHED_FIFO/RR tasks preemption and not about the purely fairness
driven SCHED_OTHER preemption latencies.
So I introduced a lazy preemption mechanism which only applies to
SCHED_OTHER tasks preempting another SCHED_OTHER task. Aside of the
existing preempt_count each tasks sports now a preempt_lazy_count
which is manipulated on lock acquiry and release. This is slightly
incorrect as for lazyness reasons I coupled this on
migrate_disable/enable so some other mechanisms get the same treatment
(e.g. get_cpu_light).
Now on the scheduler side instead of setting NEED_RESCHED this sets
NEED_RESCHED_LAZY in case of a SCHED_OTHER/SCHED_OTHER preemption and
therefor allows to exit the waking task the lock held region before
the woken task preempts. That also works better for cross CPU wakeups
as the other side can stay in the adaptive spinning loop.
For RT class preemption there is no change. This simply sets
NEED_RESCHED and forgoes the lazy preemption counter.
Initial test do not expose any observable latency increasement, but
history shows that I've been proven wrong before :)
The lazy preemption mode is per default on, but with
CONFIG_SCHED_DEBUG enabled it can be disabled via:
# echo NO_PREEMPT_LAZY >/sys/kernel/debug/sched_features
and reenabled via
# echo PREEMPT_LAZY >/sys/kernel/debug/sched_features
The test results so far are very machine and workload dependent, but
there is a clear trend that it enhances the non RT workload
performance.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
37/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: x86/entry: Use should_resched() in idtentry_exit_cond_resched()
Date: Tue, 30 Jun 2020 11:45:14 +0200
The TIF_NEED_RESCHED bit is inlined on x86 into the preemption counter.
By using should_resched(0) instead of need_resched() the same check can
be performed which uses the same variable as 'preempt_count()` which was
issued before.
Use should_resched(0) instead need_resched().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
38/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: x86: Support for lazy preemption
Date: Thu, 1 Nov 2012 11:03:47 +0100
Implement the x86 pieces for lazy preempt.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
39/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: entry: Fix the preempt lazy fallout
Date: Tue, 13 Jul 2021 07:52:52 +0200
Common code needs common defines....
Fixes: f2f9e496208c ("x86: Support for lazy preemption")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
40/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: arm: Add support for lazy preemption
Date: Wed, 31 Oct 2012 12:04:11 +0100
Implement the arm pieces for lazy preempt.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
41/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: powerpc: Add support for lazy preemption
Date: Thu, 1 Nov 2012 10:14:11 +0100
Implement the powerpc pieces for lazy preempt.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
42/55 [
Author: Anders Roxell
Email: anders.roxell@linaro.org
Subject: arch/arm64: Add lazy preempt support
Date: Thu, 14 May 2015 17:52:17 +0200
arm64 is missing support for PREEMPT_RT. The main feature which is
lacking is support for lazy preemption. The arch-specific entry code,
thread information structure definitions, and associated data tables
have to be extended to provide this support. Then the Kconfig file has
to be extended to indicate the support is available, and also to
indicate that support for full RT preemption is now available.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
43/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: arm: Disable jump-label on PREEMPT_RT.
Date: Wed, 8 Jul 2015 17:14:48 +0200
jump-labels are used to efficiently switch between two possible code
paths. To achieve this, stop_machine() is used to keep the CPU in a
known state while the opcode is modified. The usage of stop_machine()
here leads to large latency spikes which can be observed on PREEMPT_RT.
Jump labels may change the target during runtime and are not restricted
to debug or "configuration/ setup" part of a PREEMPT_RT system where
high latencies could be defined as acceptable.
Disable jump-label support on a PREEMPT_RT system.
[bigeasy: Patch description.]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20220613182447.112191-2-bigeasy@linutronix.de
]
44/55 [
Author: Yadi.hu
Email: yadi.hu@windriver.com
Subject: ARM: enable irq in translation/section permission fault handlers
Date: Wed, 10 Dec 2014 10:32:09 +0800
Probably happens on all ARM, with
CONFIG_PREEMPT_RT
CONFIG_DEBUG_ATOMIC_SLEEP
This simple program....
int main() {
*((char*)0xc0001000) = 0;
};
[ 512.742724] BUG: sleeping function called from invalid context at kernel/rtmutex.c:658
[ 512.743000] in_atomic(): 0, irqs_disabled(): 128, pid: 994, name: a
[ 512.743217] INFO: lockdep is turned off.
[ 512.743360] irq event stamp: 0
[ 512.743482] hardirqs last enabled at (0): [< (null)>] (null)
[ 512.743714] hardirqs last disabled at (0): [<c0426370>] copy_process+0x3b0/0x11c0
[ 512.744013] softirqs last enabled at (0): [<c0426370>] copy_process+0x3b0/0x11c0
[ 512.744303] softirqs last disabled at (0): [< (null)>] (null)
[ 512.744631] [<c041872c>] (unwind_backtrace+0x0/0x104)
[ 512.745001] [<c09af0c4>] (dump_stack+0x20/0x24)
[ 512.745355] [<c0462490>] (__might_sleep+0x1dc/0x1e0)
[ 512.745717] [<c09b6770>] (rt_spin_lock+0x34/0x6c)
[ 512.746073] [<c0441bf0>] (do_force_sig_info+0x34/0xf0)
[ 512.746457] [<c0442668>] (force_sig_info+0x18/0x1c)
[ 512.746829] [<c041d880>] (__do_user_fault+0x9c/0xd8)
[ 512.747185] [<c041d938>] (do_bad_area+0x7c/0x94)
[ 512.747536] [<c041d990>] (do_sect_fault+0x40/0x48)
[ 512.747898] [<c040841c>] (do_DataAbort+0x40/0xa0)
[ 512.748181] Exception stack(0xecaa1fb0 to 0xecaa1ff8)
Oxc0000000 belongs to kernel address space, user task can not be
allowed to access it. For above condition, correct result is that
test case should receive a “segment fault” and exits but not stacks.
the root cause is commit 02fe2845d6a8 ("avoid enabling interrupts in
prefetch/data abort handlers"),it deletes irq enable block in Data
abort assemble code and move them into page/breakpiont/alignment fault
handlers instead. But author does not enable irq in translation/section
permission fault handlers. ARM disables irq when it enters exception/
interrupt mode, if kernel doesn't enable irq, it would be still disabled
during translation/section permission fault.
We see the above splat because do_force_sig_info is still called with
IRQs off, and that code eventually does a:
spin_lock_irqsave(&t->sighand->siglock, flags);
As this is architecture independent code, and we've not seen any other
need for other arch to have the siglock converted to raw lock, we can
conclude that we should enable irq for ARM translation/section
permission exception.
Signed-off-by: Yadi.hu <yadi.hu@windriver.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
45/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: tty/serial/omap: Make the locking RT aware
Date: Thu, 28 Jul 2011 13:32:57 +0200
The lock is a sleeping lock and local_irq_save() is not the
optimsation we are looking for. Redo it to make it work on -RT and
non-RT.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
46/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: tty/serial/pl011: Make the locking work on RT
Date: Tue, 8 Jan 2013 21:36:51 +0100
The lock is a sleeping lock and local_irq_save() is not the optimsation
we are looking for. Redo it to make it work on -RT and non-RT.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
47/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: Allow to enable RT
Date: Fri, 11 Oct 2019 13:14:29 +0200
Allow to select RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
48/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM64: Allow to enable RT
Date: Fri, 11 Oct 2019 13:14:35 +0200
Allow to select RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
49/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: powerpc: traps: Use PREEMPT_RT
Date: Fri, 26 Jul 2019 11:30:49 +0200
Add PREEMPT_RT to the backtrace if enabled.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
50/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: powerpc/pseries/iommu: Use a locallock instead local_irq_save()
Date: Tue, 26 Mar 2019 18:31:54 +0100
The locallock protects the per-CPU variable tce_page. The function
attempts to allocate memory while tce_page is protected (by disabling
interrupts).
Use local_irq_save() instead of local_irq_disable().
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
51/55 [
Author: Bogdan Purcareata
Email: bogdan.purcareata@freescale.com
Subject: powerpc/kvm: Disable in-kernel MPIC emulation for PREEMPT_RT
Date: Fri, 24 Apr 2015 15:53:13 +0000
While converting the openpic emulation code to use a raw_spinlock_t enables
guests to run on RT, there's still a performance issue. For interrupts sent in
directed delivery mode with a multiple CPU mask, the emulated openpic will loop
through all of the VCPUs, and for each VCPUs, it call IRQ_check, which will loop
through all the pending interrupts for that VCPU. This is done while holding the
raw_lock, meaning that in all this time the interrupts and preemption are
disabled on the host Linux. A malicious user app can max both these number and
cause a DoS.
This temporary fix is sent for two reasons. First is so that users who want to
use the in-kernel MPIC emulation are aware of the potential latencies, thus
making sure that the hardware MPIC and their usage scenario does not involve
interrupts sent in directed delivery mode, and the number of possible pending
interrupts is kept small. Secondly, this should incentivize the development of a
proper openpic emulation that would be better suited for RT.
Acked-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Bogdan Purcareata <bogdan.purcareata@freescale.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
52/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: powerpc/stackprotector: work around stack-guard init from atomic
Date: Tue, 26 Mar 2019 18:31:29 +0100
This is invoked from the secondary CPU in atomic context. On x86 we use
tsc instead. On Power we XOR it against mftb() so lets use stack address
as the initial value.
Cc: stable-rt@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
53/55 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: POWERPC: Allow to enable RT
Date: Fri, 11 Oct 2019 13:14:41 +0200
Allow to select RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
54/55 [
Author: Clark Williams
Email: williams@redhat.com
Subject: sysfs: Add /sys/kernel/realtime entry
Date: Sat, 30 Jul 2011 21:55:53 -0500
Add a /sys/kernel entry to indicate that the kernel is a
realtime kernel.
Clark says that he needs this for udev rules, udev needs to evaluate
if its a PREEMPT_RT kernel a few thousand times and parsing uname
output is too slow or so.
Are there better solutions? Should it exist and return 0 on !-rt?
Signed-off-by: Clark Williams <williams@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
55/55 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: Add localversion for -RT release
Date: Fri, 8 Jul 2011 20:25:16 +0200
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
RCU_EXPERT is depended by RCU_FAST_NO_HZ, enable it to avoid
set RCU_FAST_NO_HZ to "y" failed.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/5 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs5: kbuild
Date: Tue, 26 Jul 2022 14:20:30 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/5 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs5: base
Date: Tue, 26 Jul 2022 14:21:18 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
3/5 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs5: mmap
Date: Tue, 26 Jul 2022 14:21:48 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
4/5 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs5: standalone
Date: Tue, 26 Jul 2022 14:22:14 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
5/5 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs5: core
Date: Tue, 26 Jul 2022 14:23:06 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Add support for amd-x86-64 bsp with standard and preempt-rt
kernel.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
adding MIDO configurations for enabling support for low-level MDIO bus
communication.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: pnmtologo: use relocatable file name
Date: Thu, 14 Jul 2022 14:43:46 -0400
The logo generation utility is capturing the source of the logo
in the generated .c file. The source file is absolute (as passed
by make), so the full path is captured.
This makes the source fail reproducibility tests.
We use basename() to just get the source file name, and use
that in the generated .c file.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: tools: use basename to identify file in gen-mach-types
Date: Wed, 13 Jul 2022 12:18:15 -0400
FILENAME is replaced by the full path to the executing script. If
the script is executed via a fully specified path, that is captured
in the output. Although it doesn't impact the output, it does trigger
reproducibility warnings/errors.
So we introduce a basename() function in the script and use it to
make sure the output file contains only the name of the awk script.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: lib/build_OID_registry: fix reproducibility issues
Date: Sun, 10 Jul 2022 22:56:53 -0400
The script build_OID_registry captures the full path of itself
in the generated data. This causes reproduciblity issues as the
path is captured and packaged.
We use the basename of the script instead, and that allows us
to be reprodicible, with slightly less information captured in
the output data (but the generating script can still easily
be found).
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: vt/conmakehash: improve reproducibility
Date: Sun, 10 Jul 2022 21:37:07 -0400
The file generated by conmakehash capture the application
path used to generate the file. While that can be informative,
it varies based on where the kernel was built, as the full
path is captured.
We tweak the application to use a second input as the "capture
name", and then modify the Makefile to pass the basename of
the source, making it reproducible.
This could be improved by using some sort of path mapping,
or the application manipualing argv[1] itself, but for now
this solves the reprodicibility issue.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
This option allows references to stateful objects, such as counters
and quotas. In Linux kernel since 4.10, so applicable to all branches.
Signed-off-by: Petr Gotthard <petr.gotthard@advantech.cz>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The GPIO sysfs ABI has been marked as obsolete 6 years ago [1] and has
been scheduled to be removed in 2020. And then it is restricted to be
only available to expert users by commit [2]. This restriction triggers
config warning on several BSPs due to the CONFIG_EXPERT is not enabled.
Of course we can fix these warning by enabling the CONFIG_EXPERT,
but maybe it is the time to drop this obsolete option.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fe95046e960b
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3b4feb21158f8
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
Yongxin Liu
Bruce Ashfield
Bartosz Golaszewski
Naveen Saini
Anuj Mittal
Teoh Jay Shen
Randy MacLeod
Andrei Gherzan
Kevin Hao
Liwei Song
Potin Lai
Petr Gotthard