| Age | Commit message (Collapse) | Author |
|---|
|
In commit e2c73a6860bd ("rcu: Remove the RCU_FAST_NO_HZ Kconfig option")
the so named option was removed from the v5.17 kernel.
We should get it out of our active branches to prevent a warning.
Signed-off-by: Paul Gortmaker <paulg@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
nftable ptests do create interfaces of veth type and this
feature would be needed to enable those tests
e.g. from tests/shell/testcases/packetpath/vlan_8021ad_tag
ip link add veth0 netns $ns1 type veth peer name veth0 netns $ns2
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
We ended up with two lxc fragments when meta-virtualization
was sync'd to the kernel-cache
We can make our existing feature include the new one and
nothing will break.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs: adjust for v6.9+
Date: Wed, 3 Apr 2024 10:15:47 -0400
The following commit drops SLAB_MEM_SPREAD, so we remove it
from aufs.
commit cdeeaaba174886aa6c1ff4c0c5449c5066dbe82f
Author: Vlastimil Babka <vbabka@suse.cz>
Date: Fri Feb 23 19:27:17 2024 +0100
mm, slab: deprecate SLAB_MEM_SPREAD flag
The SLAB_MEM_SPREAD flag used to be implemented in SLAB, which was
removed. SLUB instead relies on the page allocator's NUMA policies.
Change the flag's value to 0 to free up the value it had, and mark it
for full removal once all users are gone.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Closes: https://lore.kernel.org/all/20240131172027.10f64405@gandalf.local.home/
Reviewed-and-tested-by: Xiongwei Song <xiongwei.song@windriver.com>
Reviewed-by: Chengming Zhou <chengming.zhou@linux.dev>
Reviewed-by: Roman Gushchin <roman.gushchin@linux.dev>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Several nftables ptest testcases failed due to missing features. The
following kernel configuration options are added as part of the missing
features:
- NFT_FIB_INET (tristate "Netfilter nf_tables fib inet support")
This option allows using the FIB expression from the inet table.
The lookup will be delegated to the IPv4 or IPv6 FIB depending
on the protocol of the packet.
- NFT_FIB_IPV4 (tristate "nf_tables fib / ip route lookup support")
This module enables IPv4 FIB lookups, e.g. for reverse path filtering.
It also allows query of the FIB for the route type, e.g. local, unicast,
multicast or blackhole.
- NFT_FIB_IPV6 (tristate "nf_tables fib / ipv6 route lookup support")
This module enables IPv6 FIB lookups, e.g. for reverse path filtering.
It also allows query of the FIB for the route type, e.g. local, unicast,
multicast or blackhole.
Adding those three kernel configuration options above pass the following
ptest testcases:
- tests/shell/testcases/parsing/large_rule_pipe
Previously failed due to using rule:
meta nfproto ipv6 fib saddr . iif oif missing drop
- tests/shell/testcases/nft-f/sample-ruleset
Previously failed due to using rules:
fib saddr . iif oif eq 0 counter drop
fib daddr type { broadcast, multicast, anycast } counter drop
fib daddr type { broadcast, multicast, anycast } counter drop
fib daddr type { broadcast, multicast, anycast } counter drop
- tests/shell/testcases/optimizations/ruleset
Previously failed due to using rule:
fib daddr type broadcast drop
Signed-off-by: William Lyu <William.Lyu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Starting from kernel v6.2 (including all rc versions),
CONFIG_NFT_OBJREF has become builtin and cannot be disabled [1]. So,
this configure option is removed from nf_tables.cfg.
References
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d037abc2414b4539401e0e6aa278bedc4628ad69
Signed-off-by: William Lyu <William.Lyu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Add MULTIQ and NET_EMATCH config.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Add xdp feature config.
Signed-off-by: Xiaolei Wang <xiaolei.wang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
CONFIG_VFIO_MDEV wasn't a user choice after kerne commit
8bf8c5ee1f38 ("vfio-mdev: turn VFIO_MDEV into a selectable symbol").
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
CONFIG_VFIO_VIRQFD was changed to bool in kernel commit
e2d55709398e ("vfio: Fold vfio_virqfd.ko into vfio.ko") and
it is not user selectable.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.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 will enable kernel options for Intel Sound Open Firmware support,
only fewer Intel platforms use Soundwire audio by default, but when SOF
enabled, this will replace HD audio driver which most of Intel boards
used. So we need enable it carefully only for some specific boards.
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Otherwise the audit will notice that "y " was requested but "y" was set.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
This was removed in kernel a9ee6cf (5.14 onwards).
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Similar to the argument of why we shouldn't force NUMA on everyone, the
9 chip registered ECC RAM type stuff also tends to be found mostly on
larger server type stuff and less so on embedded targets.
We already have a skeleton EDAC feature, so move the features over
there. One could argue that we might want to separate into arch
specific config fragments, but to me - that seems overkill at this
point in time.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
A user reported getting NUMA warnings like the ones reported here:
https://www.suse.com/support/kb/doc/?id=000021040
"Fail to get numa node for CPU:0 bus:0 dev:0 fn:1"
...and repeated for every core on the platform. Distracting.
When I asked if it was a crazy big server system with multiple CPU
sockets and localized RAM near each socket - the answer was "no".
Turns out they didn't choose NUMA support - rather we did it for them.
Yocto has been and still remains more "embedded leaning". That is not
to say we can't support NUMA. We just shouldn't be enabling it by
default in the base x86-64 config fragment that everyone uses.
Move the two NUMA settings that were not in our existing numa.cfg
feature out of the BSP and into the feature.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Add optee config values for inclusion in BSPs that require
support.
We'll extend this in the future via KERNEL_FEATURES and
distro feature coordination.
Signed-off-by: Meng Li <Meng.Li@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
According to the kernel self protection page[1], add recommended options to
features/security for aarch64/arm64.
Ref:
[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings#arm64
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
CONFIG_DEBUG_CREDENTIALS
kernel upstream already removed the CONFIG_DEBUG_CREDENTIALS[1],
this causes do_kernel_configcheck report warnings:
[INFO]: the following symbols were not found in the active configuration:
- CONFIG_DEBUG_CREDENTIALS
[1] https://git.kernel.org/linus/ae191417
Kernel's 6.7+ need this change.
Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
The driver was removed in v6.2.
https://github.com/torvalds/linux/commit/1dd1b521be85417ec409062319520ca26c1c589e
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: correct do_splice_from prototype
Date: Thu, 25 Jan 2024 11:17:19 -0500
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Error:
4.24.0-00005/qat17/quickassist/qat/drivers/crypto/qat/
qat_common/../../../../compat/qat_compat.c:401:19: error:
'struct pci_dev' has no member named 'aer_cap'; did you mean 'ats_cap'?
| 401 | if (!dev->aer_cap)
| | ^~~~~~~
| | ats_cap
https://github.com/torvalds/linux/blob/296455ade1fdcf5f8f8c033201633b60946c589a/include/linux/pci.h#L339
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@gmail.com
Subject: aufs: update remove_page to remove_folio
Date: Tue, 23 Jan 2024 09:56:24 -0500
Commit af7628d6ec19 [fs: convert error_remove_page to
error_remove_folio]
switches remove_page to the folio equivalent. We switch
the aufs definitions to match.
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>
|
|
Add some configs to harden protection:
CONFIG_HW_RANDOM_TPM=y Exposing the TPM's Random Number Generator as a hwrng device.
CONFIG_DEBUG_WX=y Warn on W+X mappings at boot.
CONFIG_SECURITY_DMESG_RESTRICT=y Restrict unprivileged access to the kernel syslog.
CONFIG_LDISC_AUTOLOAD=n Disable automatically load TTY Line Disciplines.
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: He Zhe
Email: zhe.he@windriver.com
Subject: aufs: i_op: Add handling for au_pin_hdir_set_owner with RT kernel
Date: Fri, 5 Jan 2024 18:57:18 +0800
In RT kernel rw_semaphore uses rt_mutex whose owner should be set to the
task. Add a condition to handle both cases to avoid the following build error
for PREEMPT_RT kernel.
fs/aufs/i_op.c: In function 'au_pin_hdir_set_owner':
fs/aufs/i_op.c:639:52: error: 'struct rw_semaphore' has no member named 'owner'
639 | atomic_long_set(&p->hdir->hi_inode->i_rwsem.owner, (long)task);
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Unfortunately linux-stable backported this:
Subject: ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig
From: Nayna Jain <nayna@linux.ibm.com>
[ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ]
Time to remove "IMA_TRUSTED_KEYRING".
...to all releases still being maintained.
stable-queue$git grep -l 5087fd9e80e539
releases/5.10.195/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
releases/5.15.132/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
releases/5.4.257/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
releases/6.1.53/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
releases/6.4.16/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
releases/6.5.3/ima-remove-deprecated-ima_trusted_keyring-kconfig.patch
So now when someone uses the feature, it triggers a do_kernel_configcheck
warning when the audit runs.
We added this file way back in 2019 so this fix will be needed on all
active branches that are using an LTS linux-stable kernel listed above.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
commit 2a2fffb488a3c5ea9c06d0b572c90c4aa78709b6
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date: Sun Aug 13 10:22:54 2023 +0200
media: remove the old videobuf framework
The last driver that still used this old framework has been converted
to the videobuf2 framework. So it is now time to delete the old videobuf
code.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs: fix v6.7 kernel build compilation
Date: Wed, 22 Nov 2023 12:06:29 -0500
Adapting aufs to the following upstream commits:
commit 12cd44023651666bd44baa36a5c999698890debb
Author: Jeff Layton <jlayton@kernel.org>
Date: Fri Sep 29 09:05:52 2023 -0400
fs: rename inode i_atime and i_mtime fields
Rename these two fields to discourage direct access (and to help ensure
that we mop up any leftover direct accesses).
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
commit 3e15dcf77b23b8e9b9b7f3c0d4def8fe9c12c534
Author: Amir Goldstein <amir73il@gmail.com>
Date: Fri Sep 8 16:28:59 2023 +0300
fs: rename __mnt_{want,drop}_write*() helpers
Before exporting these helpers to modules, make their names more
meaningful.
The names mnt_{get,put)_write_access*() were chosen, because they rhyme
with the inode {get,put)_write_access() helpers, which have a very close
meaning for the inode object.
Suggested-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/r/20230817-anfechtbar-ruhelosigkeit-8c6cca8443fc@brauner/
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Message-Id: <20230908132900.2983519-2-amir73il@gmail.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
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: yaffs: fix mtime/itime field access
Date: Wed, 22 Nov 2023 12:04:28 -0500
Adapting our inode field access to the following upstream
commit:
commit 12cd44023651666bd44baa36a5c999698890debb
Author: Jeff Layton <jlayton@kernel.org>
Date: Fri Sep 29 09:05:52 2023 -0400
fs: rename inode i_atime and i_mtime fields
Rename these two fields to discourage direct access (and to help ensure
that we mop up any leftover direct accesses).
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
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>
|
|
For tools like spdx and debuggers to work with the kernel, we
require extra information. That is provided by the DEBUG_INFO
flags.
In that same fragment, some runtime debugging is being enabled
and that adds signficant overhead to the kernel.
Let's start a new runtime debug fragment with DEBUG_PREEMPT
and locking. We can add more to this in the future.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
CONFIG_DEVMEM was mistakenly not enabled, which defeats
CONFIG_STRICT_DEVMEM and friends, as it completely removes all
/dev/mem support.
Signed-off-by: C. Andy Martin <cam@myfastmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
VIDEO_STK1160_COMMON has been merged in VIDEO_STK1160 starting v6.5.
https://github.com/torvalds/linux/commit/7f7ac101236bd020681f122089b611eca8e507ac
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/83 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: sched: Constrain locks in sched_submit_work()
Date: Fri, 8 Sep 2023 18:22:48 +0200
Even though sched_submit_work() is ran from preemptible context,
it is discouraged to have it use blocking locks due to the recursion
potential.
Enforce this.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-2-bigeasy@linutronix.de
]
2/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: Avoid unconditional slowpath for DEBUG_RT_MUTEXES
Date: Fri, 8 Sep 2023 18:22:49 +0200
With DEBUG_RT_MUTEXES enabled the fast-path rt_mutex_cmpxchg_acquire()
always fails and all lock operations take the slow path.
Provide a new helper inline rt_mutex_try_acquire() which maps to
rt_mutex_cmpxchg_acquire() in the non-debug case. For the debug case
it invokes rt_mutex_slowtrylock() which can acquire a non-contended
rtmutex under full debug coverage.
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>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-3-bigeasy@linutronix.de
]
3/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: sched: Extract __schedule_loop()
Date: Fri, 8 Sep 2023 18:22:50 +0200
There are currently two implementations of this basic __schedule()
loop, and there is soon to be a third.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-4-bigeasy@linutronix.de
]
4/83 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: sched: Provide rt_mutex specific scheduler helpers
Date: Fri, 8 Sep 2023 18:22:51 +0200
With PREEMPT_RT there is a rt_mutex recursion problem where
sched_submit_work() can use an rtlock (aka spinlock_t). More
specifically what happens is:
mutex_lock() /* really rt_mutex */
...
__rt_mutex_slowlock_locked()
task_blocks_on_rt_mutex()
// enqueue current task as waiter
// do PI chain walk
rt_mutex_slowlock_block()
schedule()
sched_submit_work()
...
spin_lock() /* really rtlock */
...
__rt_mutex_slowlock_locked()
task_blocks_on_rt_mutex()
// enqueue current task as waiter *AGAIN*
// *CONFUSION*
Fix this by making rt_mutex do the sched_submit_work() early, before
it enqueues itself as a waiter -- before it even knows *if* it will
wait.
[[ basically Thomas' patch but with different naming and a few asserts
added ]]
Originally-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-5-bigeasy@linutronix.de
]
5/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: Use rt_mutex specific scheduler helpers
Date: Fri, 8 Sep 2023 18:22:52 +0200
Have rt_mutex use the rt_mutex specific scheduler helpers to avoid
recursion vs rtlock on the PI state.
[[ peterz: adapted to new names ]]
Reported-by: Crystal Wood <swood@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-6-bigeasy@linutronix.de
]
6/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: locking/rtmutex: Add a lockdep assert to catch potential nested blocking
Date: Fri, 8 Sep 2023 18:22:53 +0200
There used to be a BUG_ON(current->pi_blocked_on) in the lock acquisition
functions, but that vanished in one of the rtmutex overhauls.
Bring it back in form of a lockdep assert to catch code paths which take
rtmutex based locks with current::pi_blocked_on != NULL.
Reported-by: Crystal Wood <swood@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230908162254.999499-7-bigeasy@linutronix.de
]
7/83 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: futex/pi: Fix recursive rt_mutex waiter state
Date: Fri, 15 Sep 2023 17:19:44 +0200
Some new assertions pointed out that the existing code has nested rt_mutex wait
state in the futex code.
Specifically, the futex_lock_pi() cancel case uses spin_lock() while there
still is a rt_waiter enqueued for this task, resulting in a state where there
are two waiters for the same task (and task_struct::pi_blocked_on gets
scrambled).
The reason to take hb->lock at this point is to avoid the wake_futex_pi()
EAGAIN case.
This happens when futex_top_waiter() and rt_mutex_top_waiter() state becomes
inconsistent. The current rules are such that this inconsistency will not be
observed.
Notably the case that needs to be avoided is where futex_lock_pi() and
futex_unlock_pi() interleave such that unlock will fail to observe a new
waiter.
*However* the case at hand is where a waiter is leaving, in this case the race
means a waiter that is going away is not observed -- which is harmless,
provided this race is explicitly handled.
This is a somewhat dangerous proposition because the converse race is not
observing a new waiter, which must absolutely not happen. But since the race is
valid this cannot be asserted.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Tested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20230915151943.GD6743@noisy.programming.kicks-ass.net
]
8/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: signal: Add proper comment about the preempt-disable in ptrace_stop().
Date: Thu, 3 Aug 2023 12:09:31 +0200
Commit 53da1d9456fe7 ("fix ptrace slowness") added a preempt-disable section
between read_unlock() and the following schedule() invocation without
explaining why it is needed.
Replace the comment with an explanation why this is needed. Clarify that
it is needed for correctness but for performance reasons.
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20230803100932.325870-2-bigeasy@linutronix.de
]
9/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: signal: Don't disable preemption in ptrace_stop() on PREEMPT_RT.
Date: Thu, 3 Aug 2023 12:09:32 +0200
On PREEMPT_RT keeping preemption disabled during the invocation of
cgroup_enter_frozen() is 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.
The preempt-disabled section is only for performance optimisation
reasons and can be avoided.
Extend the comment and don't disable preemption before scheduling on
PREEMPT_RT.
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20230803100932.325870-3-bigeasy@linutronix.de
]
10/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/amd/display: Remove migrate_en/dis from dc_fpu_begin().
Date: Thu, 21 Sep 2023 16:15:12 +0200
This is a revert of the commit mentioned below while it is not wrong, as
in the kernel will explode, having migrate_disable() here it is
complete waste of resources.
Additionally commit message is plain wrong the review tag does not make
it any better. The migrate_disable() interface has a fat comment
describing it and it includes the word "undesired" in the headline which
should tickle people to read it before using it.
Initially I assumed it is worded too harsh but now I beg to differ.
The reviewer of the original commit, even not understanding what
migrate_disable() does should ask the following:
- migrate_disable() is added only to the CONFIG_X86 block and it claims
to protect fpu_recursion_depth. Why are the other the architectures
excluded?
- migrate_disable() is added after fpu_recursion_depth was modified.
Shouldn't it be added before the modification or referencing takes
place?
Moving on.
Disabling preemption DOES prevent CPU migration. A task, that can not be
pushed away from the CPU by the scheduler (due to disabled preemption)
can not be pushed or migrated to another CPU.
Disabling migration DOES NOT ensure consistency of per-CPU variables. It
only ensures that the task acts always on the same per-CPU variable. The
task remains preemptible meaning multiple tasks can access the same
per-CPU variable. This in turn leads to inconsistency for the statement
*pcpu -= 1;
with two tasks on one CPU and a preemption point during the RMW
operation:
Task A Task B
read pcpu to reg # 0
inc reg # 0 -> 1
read pcpu to reg # 0
inc reg # 0 -> 1
write reg to pcpu # 1
write reg to pcpu # 1
At the end pcpu reads 1 but should read 2 instead. Boom.
get_cpu_ptr() already contains a preempt_disable() statement. That means
that the per-CPU variable can only be referenced by a single task which
is currently running. The only inconsistency that can occur if the
variable is additionally accessed from an interrupt.
Remove migrate_disable/enable() from dc_fpu_begin/end().
Cc: Tianci Yin <tianci.yin@amd.com>
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Fixes: 0c316556d1249 ("drm/amd/display: Disable migration to ensure consistency of per-CPU variable")
Link: https://lore.kernel.org/r/20230921141516.520471-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
11/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/amd/display: Simplify the per-CPU usage.
Date: Thu, 21 Sep 2023 16:15:13 +0200
The fpu_recursion_depth counter is used to ensure that dc_fpu_begin()
can be invoked multiple times while the FPU-disable function itself is
only invoked once. Also the counter part (dc_fpu_end()) is ballanced
properly.
Instead of using the get_cpu_ptr() dance around the inc it is simpler to
increment the per-CPU variable directly. Also the per-CPU variable has
to be incremented and decremented on the same CPU. This is ensured by
the inner-part which disables preemption. This is kind of not obvious,
works and the preempt-counter is touched a few times for no reason.
Disable preemption before incrementing fpu_recursion_depth for the first
time. Keep preemption disabled until dc_fpu_end() where the counter is
decremented making it obvious that the preemption has to stay disabled
while the counter is non-zero.
Use simple inc/dec functions.
Remove the nested preempt_disable/enable functions which are now not
needed.
Link: https://lore.kernel.org/r/20230921141516.520471-3-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
12/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/amd/display: Add a warning if the FPU is used outside from task context.
Date: Thu, 21 Sep 2023 16:15:14 +0200
Add a warning if the FPU is used from any context other than task
context. This is only precaution since the code is not able to be used
from softirq while the API allows it on x86 for instance.
Link: https://lore.kernel.org/r/20230921141516.520471-4-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
13/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/amd/display: Move the memory allocation out of dcn20_validate_bandwidth_fp().
Date: Thu, 21 Sep 2023 16:15:16 +0200
dcn20_validate_bandwidth_fp() is invoked while FPU access has been
enabled. FPU access requires disabling preemption even on PREEMPT_RT.
It is not possible to allocate memory with disabled preemption even with
GFP_ATOMIC on PREEMPT_RT.
Move the memory allocation before FPU access is enabled.
To preserve previous "clean" state of "pipes" add a memset() before the
second invocation of dcn20_validate_bandwidth_internal() where the
variable is used.
Link: https://lore.kernel.org/r/20230921141516.520471-6-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
14/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: drm/amd/display: Move the memory allocation out of dcn20_validate_bandwidth_fp().
Date: Thu, 21 Sep 2023 16:15:16 +0200
dcn20_validate_bandwidth_fp() is invoked while FPU access has been
enabled. FPU access requires disabling preemption even on PREEMPT_RT.
It is not possible to allocate memory with disabled preemption even with
GFP_ATOMIC on PREEMPT_RT.
Move the memory allocation before FPU access is enabled.
To preserve previous "clean" state of "pipes" add a memset() before the
second invocation of dcn20_validate_bandwidth_internal() where the
variable is used.
Link: https://lore.kernel.org/r/20230921141516.520471-6-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
15/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: net: Avoid the IPI to free the
Date: Mon, 15 Aug 2022 17:29:50 +0200
skb_attempt_defer_free() collects a skbs, which was allocated on a
remote CPU, on a per-CPU list. These skbs are either freed on that
remote CPU once the CPU enters NET_RX or an remote IPI function is
invoked in to raise the NET_RX softirq if a threshold of pending skb has
been exceeded.
This remote IPI can cause the wakeup of ksoftirqd on PREEMPT_RT if the
remote CPU idle was idle. This is undesired because once the ksoftirqd
is running it will acquire all pending softirqs and they will not be
executed as part of the threaded interrupt until ksoftird goes idle
again.
To void all this, schedule the deferred clean up from a worker.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
16/83 [
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>
]
17/83 [
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>
]
18/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: sched/rt: Don't try push tasks if there are none.
Date: Tue, 1 Aug 2023 17:26:48 +0200
I have a RT task X at a high priority and cyclictest on each CPU with
lower priority than X's. If X is active and each CPU wakes their own
cylictest thread then it ends in a longer rto_push storm.
A random CPU determines via balance_rt() that the CPU on which X is
running needs to push tasks. X has the highest priority, cyclictest is
next in line so there is nothing that can be done since the task with
the higher priority is not touched.
tell_cpu_to_push() increments rto_loop_next and schedules
rto_push_irq_work_func() on X's CPU. The other CPUs also increment the
loop counter and do the same. Once rto_push_irq_work_func() is active it
does nothing because it has _no_ pushable tasks on its runqueue. Then
checks rto_next_cpu() and decides to queue irq_work on the local CPU
because another CPU requested a push by incrementing the counter.
I have traces where ~30 CPUs request this ~3 times each before it
finally ends. This greatly increases X's runtime while X isn't making
much progress.
Teach rto_next_cpu() to only return CPUs which also have tasks on their
runqueue which can be pushed away. This does not reduce the
tell_cpu_to_push() invocations (rto_loop_next counter increments) but
reduces the amount of issued rto_push_irq_work_func() if nothing can be
done. As the result the overloaded CPU is blocked less often.
There are still cases where the "same job" is repeated several times
(for instance the current CPU needs to resched but didn't yet because
the irq-work is repeated a few times and so the old task remains on the
CPU) but the majority of request end in tell_cpu_to_push() before an IPI
is issued.
Reviewed-by: "Steven Rostedt (Google)" <rostedt@goodmis.org>
Link: https://lore.kernel.org/r/20230801152648._y603AS_@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
19/83 [
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>
]
20/83 [
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>
]
21/83 [
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
]
22/83 [
Author: Junxiao Chang
Email: junxiao.chang@intel.com
Subject: softirq: Wake ktimers thread also in softirq.
Date: Mon, 20 Feb 2023 09:12:20 +0100
If the hrtimer is raised while a softirq is processed then it does not
wake the corresponding ktimers thread. This is due to the optimisation in the
irq-exit path which is also used to wake the ktimers thread. For the other
softirqs, this is okay because the additional softirq bits will be handled by
the currently running softirq handler.
The timer related softirq bits are added to a different variable and rely on
the ktimers thread.
As a consuequence the wake up of ktimersd is delayed until the next timer tick.
Always wake the ktimers thread if a timer related softirq is pending.
Reported-by: Peh, Hock Zhang <hock.zhang.peh@intel.com>
Signed-off-by: Junxiao Chang <junxiao.chang@intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
23/83 [
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. The spinlock_t lock becomes a sleeping
lock on PREEMPT_RT and it can not be acquired in this context. In this locked
section, zs_free() acquires a zs_pool::lock, and there is access to
zram::wb_limit_lock.
Use a spinlock_t on PREEMPT_RT for locking and set/ clear ZRAM_LOCK bit 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
Link: https://lore.kernel.org/20230323161830.jFbWCosd@linutronix.de
]
24/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: preempt: Put preempt_enable() within an instrumentation*() section.
Date: Wed, 8 Mar 2023 16:29:38 +0100
Callers of preempt_enable() can be within an noinstr section leading to:
| vmlinux.o: warning: objtool: native_sched_clock+0x97: call to preempt_schedule_notrace_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: kvm_clock_read+0x22: call to preempt_schedule_notrace_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: local_clock+0xb4: call to preempt_schedule_notrace_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: enter_from_user_mode+0xea: call to preempt_schedule_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: syscall_enter_from_user_mode+0x140: call to preempt_schedule_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: syscall_enter_from_user_mode_prepare+0xf2: call to preempt_schedule_thunk() leaves .noinstr.text section
| vmlinux.o: warning: objtool: irqentry_enter_from_user_mode+0xea: call to preempt_schedule_thunk() leaves .noinstr.text section
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20230309072724.3F6zRkvw@linutronix.de
]
25/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: sched/core: Provide a method to check if a task is PI-boosted.
Date: Fri, 4 Aug 2023 13:30:37 +0200
Provide a method to check if a task inherited the priority from another
task. This happens if a task owns a lock which is requested by a task
with higher priority. This can be used as a hint to add a preemption
point to the critical section.
Provide a function which reports true if the task is PI-boosted.
Link: https://lore.kernel.org/r/20230804113039.419794-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
26/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: softirq: Add function to preempt serving softirqs.
Date: Fri, 4 Aug 2023 13:30:38 +0200
Add a functionality for the softirq handler to preempt its current work
if needed. The softirq core has no particular state. It reads and resets
the pending softirq bits and then processes one after the other.
It can already be preempted while it invokes a certain softirq handler.
By enabling the BH the softirq core releases the per-CPU bh lock which
serializes all softirq handler. It is safe to do as long as the code
does not expect any serialisation in between. A typical scenarion would
after the invocation of callback where no state needs to be preserved
before the next callback is invoked.
Add functionaliry to preempt the serving softirqs.
Link: https://lore.kernel.org/r/20230804113039.419794-3-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
27/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: time: Allow to preempt after a callback.
Date: Fri, 4 Aug 2023 13:30:39 +0200
The TIMER_SOFTIRQ handler invokes timer callbacks of the expired timers.
Before each invocation the timer_base::lock is dropped. The only lock
that is still held is the timer_base::expiry_lock and the per-CPU
bh-lock as part of local_bh_disable(). The former is released as part
of lock up prevention if the timer is preempted by the caller which is
waiting for its completion.
Both locks are already released as part of timer_sync_wait_running().
This can be extended by also releasing in bh-lock. The timer core does
not rely on any state that is serialized by the bh-lock. The timer
callback expects the bh-state to be serialized by the lock but there is
no need to keep state synchronized while invoking multiple callbacks.
Preempt handling softirqs and release all locks after a timer invocation
if the current has inherited priority.
Link: https://lore.kernel.org/r/20230804113039.419794-4-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
28/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: Add non-BKL console basic infrastructure
Date: Sun, 11 Sep 2022 00:28:01 +0200
The current console/printk subsystem is protected by a Big Kernel Lock,
(aka console_lock) which has ill defined semantics and is more or less
stateless. This puts severe limitations on the console subsystem and
makes forced takeover and output in emergency and panic situations a
fragile endavour which is based on try and pray.
The goal of non-BKL consoles is to break out of the console lock jail
and to provide a new infrastructure that avoids the pitfalls and
allows console drivers to be gradually converted over.
The proposed infrastructure aims for the following properties:
- Per console locking instead of global locking
- Per console state which allows to make informed decisions
- Stateful handover and takeover
As a first step state is added to struct console. The per console state
is an atomic_long_t with a 32bit bit field and on 64bit also a 32bit
sequence for tracking the last printed ringbuffer sequence number. On
32bit the sequence is separate from state for obvious reasons which
requires handling a few extra race conditions.
Reserve state bits, which will be populated later in the series. Wire
it up into the console register/unregister functionality and exclude
such consoles from being handled in the console BKL mechanisms. Since
the non-BKL consoles will not depend on the console lock/unlock dance
for printing, only perform said dance if a BKL console is registered.
The decision to use a bitfield was made as using a plain u32 with
mask/shift operations turned out to result in uncomprehensible code.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
29/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add acquire/release logic
Date: Sun, 11 Sep 2022 00:28:02 +0200
Add per console acquire/release functionality. The console 'locked'
state is a combination of several state fields:
- The 'locked' bit
- The 'cpu' field that denotes on which CPU the console is locked
- The 'cur_prio' field that contains the severity of the printk
context that owns the console. This field is used for decisions
whether to attempt friendly handovers and also prevents takeovers
from a less severe context, e.g. to protect the panic CPU.
The acquire mechanism comes with several flavours:
- Straight forward acquire when the console is not contended
- Friendly handover mechanism based on a request/grant handshake
The requesting context:
1) Puts the desired handover state (CPU nr, prio) into a
separate handover state
2) Sets the 'req_prio' field in the real console state
3) Waits (with a timeout) for the owning context to handover
The owning context:
1) Observes the 'req_prio' field set
2) Hands the console over to the requesting context by
switching the console state to the handover state that was
provided by the requester
- Hostile takeover
The new owner takes the console over without handshake
This is required when friendly handovers are not possible,
i.e. the higher priority context interrupted the owning context
on the same CPU or the owning context is not able to make
progress on a remote CPU.
The release is the counterpart which either releases the console
directly or hands it gracefully over to a requester.
All operations on console::atomic_state[CUR|REQ] are atomic
cmpxchg based to handle concurrency.
The acquire/release functions implement only minimal policies:
- Preference for higher priority contexts
- Protection of the panic CPU
All other policy decisions have to be made at the call sites.
The design allows to implement the well known:
acquire()
output_one_line()
release()
algorithm, but also allows to avoid the per line acquire/release for
e.g. panic situations by doing the acquire once and then relying on
the panic CPU protection for the rest.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
30/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add buffer management
Date: Sun, 11 Sep 2022 00:28:04 +0200
In case of hostile takeovers it must be ensured that the previous
owner cannot scribble over the output buffer of the emergency/panic
context. This is achieved by:
- Adding a global output buffer instance for early boot (pre per CPU
data being available).
- Allocating an output buffer per console for threaded printers once
printer threads become available.
- Allocating per CPU output buffers per console for printing from
all contexts not covered by the other buffers.
- Choosing the appropriate buffer is handled in the acquire/release
functions.
The output buffer is wrapped into a separate data structure so other
context related fields can be added in later steps.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
31/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add sequence handling
Date: Sun, 11 Sep 2022 00:28:06 +0200
On 64bit systems the sequence tracking is embedded into the atomic
console state, on 32bit it has to be stored in a separate atomic
member. The latter needs to handle the non-atomicity in hostile
takeover cases, while 64bit can completely rely on the state
atomicity.
The ringbuffer sequence number is 64bit, but having a 32bit
representation in the console is sufficient. If a console ever gets
more than 2^31 records behind the ringbuffer then this is the least
of the problems.
On acquire() the atomic 32bit sequence number is expanded to 64 bit
by folding the ringbuffer's sequence into it carefully.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
32/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add print state functions
Date: Sun, 11 Sep 2022 00:28:07 +0200
Provide three functions which are related to the safe handover
mechanism and allow console drivers to denote takeover unsafe
sections:
- console_can_proceed()
Invoked by a console driver to check whether a handover request
is pending or whether the console was taken over in a hostile
fashion.
- console_enter/exit_unsafe()
Invoked by a console driver to denote that the driver output
function is about to enter or to leave an critical region where a
hostile take over is unsafe. These functions are also
cancellation points.
The unsafe state is stored in the console state and allows a
takeover attempt to make informed decisions whether to take over
and/or output on such a console at all. The unsafe state is also
available to the driver in the write context for the
atomic_write() output function so the driver can make informed
decisions about the required actions or take a special emergency
path.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
33/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add emit function and callback functions for atomic printing
Date: Sun, 11 Sep 2022 00:28:10 +0200
Implement an emit function for non-BKL consoles to output printk
messages. It utilizes the lockless printk_get_next_message() and
console_prepend_dropped() functions to retrieve/build the output
message. The emit function includes the required safety points to
check for handover/takeover and calls a new write_atomic callback
of the console driver to output the message. It also includes proper
handling for updating the non-BKL console sequence number.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
34/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Introduce printer threads
Date: Sun, 11 Sep 2022 00:28:12 +0200
Add the infrastructure to create a printer thread per console along
with the required thread function, which is takeover/handover aware.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
35/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add printer thread wakeups
Date: Tue, 28 Feb 2023 10:01:59 +0000
Add a function to wakeup the printer threads. Use the new function
when:
- records are added to the printk ringbuffer
- consoles are started
- consoles are resumed
The actual waking is performed via irq_work so that the wakeup can
be triggered from any context.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
36/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Add write context storage for atomic writes
Date: Sun, 11 Sep 2022 00:28:13 +0200
The number of consoles is unknown at compile time and allocating
write contexts on stack in emergency/panic situations is not desired
either.
Allocate a write context array (one for each priority level) along
with the per CPU output buffers, thus allowing atomic contexts on
multiple CPUs and priority levels to execute simultaneously without
clobbering each other's write context.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
37/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: printk: nobkl: Provide functions for atomic write enforcement
Date: Sun, 11 Sep 2022 00:28:15 +0200
Threaded printk is the preferred mechanism to tame the noisyness of
printk, but WARN/OOPS/PANIC require printing out immediately since
the printer threads might not be able to run.
Add per CPU state to denote the priority/urgency of the output and
provide functions to flush the printk backlog for priority elevated
contexts and when the printing threads are not available (such as
early boot).
Note that when a CPU is in a priority elevated state, flushing only
occurs when dropping back to a lower priority. This allows the full
set of printk records (WARN/OOPS/PANIC output) to be stored in the
ringbuffer before beginning to flush the backlog.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
38/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: nobkl: Stop threads on shutdown/reboot
Date: Mon, 27 Feb 2023 17:59:01 +0100
Register a syscore_ops shutdown function to stop all threaded
printers on shutdown/reboot. This allows printk to transition back
to atomic printing in order to provide a robust mechanism for
outputting the final messages.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
39/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: tty: tty_io: Show non-BKL consoles as active
Date: Fri, 10 Mar 2023 13:08:01 +0000
/sys/class/tty/console/active shows the consoles that are currently
registered and enabled and are able to print (i.e. have implemented
a write() callback). This is used by userspace programs such as
systemd's systemd-getty-generator to determine where consoles are
in order to automatically start a getty instance.
The non-BKL consoles do not implement write() but also should be
shown as an active console. Expand the conditions to also check if
the callbacks write_thread() or write_atomic() are implemented for
non-BKL consoles.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
40/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: proc: consoles: Add support for non-BKL consoles
Date: Fri, 10 Mar 2023 13:36:01 +0000
Show 'W' if a non-BKL console implements write_thread() or
write_atomic().
Add a new flag 'N' to show if it is a non-BKL console.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
41/83 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: kernel/panic: Add atomic write enforcement to warn/panic
Date: Sun, 11 Sep 2022 00:28:17 +0200
Invoke the atomic write enforcement functions for warn/panic to
ensure that the information gets out to the consoles.
For the panic case, add explicit intermediate atomic flush calls to
ensure immediate flushing at important points. Otherwise the atomic
flushing only occurs when dropping out of the elevated priority,
which for panic may never happen.
It is important to note that if there are any legacy consoles
registered, they will be attempting to directly print from the
printk-caller context, which may jeopardize the reliability of the
atomic consoles. Optimally there should be no legacy consoles
registered.
Co-developed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Thomas Gleixner (Intel) <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
42/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: rcu: Add atomic write enforcement for rcu stalls
Date: Wed, 14 Sep 2022 08:17:13 +0206
Invoke the atomic write enforcement functions for rcu stalls to
ensure that the information gets out to the consoles.
It is important to note that if there are any legacy consoles
registered, they will be attempting to directly print from the
printk-caller context, which may jeopardize the reliability of the
atomic consoles. Optimally there should be no legacy consoles
registered.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
43/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: Perform atomic flush in console_flush_on_panic()
Date: Tue, 28 Feb 2023 13:55:00 +0000
Typically the panic() function will take care of atomic flushing the
non-BKL consoles on panic. However, there are several users of
console_flush_on_panic() outside of panic().
Also perform atomic flushing in console_flush_on_panic(). A new
function cons_force_seq() is implemented to support the
mode=CONSOLE_REPLAY_ALL feature.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
44/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: only disable if actually unregistered
Date: Tue, 7 Mar 2023 18:22:26 +0000
Currently in unregister_console() a printk message is generated and
the console is disabled, even it was never registered. There are
code paths (such as uart_remove_one_port()) that call
unregister_console() even if the console is not registered.
It is confusing to see messages about consoles being disabled that
were never disabled. Move the printk and disabling later, when it
is known that the console is actually registered.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
45/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: Add threaded printing support for BKL consoles.
Date: Sun, 11 Sep 2022 00:28:12 +0200
Add threaded printing support for BKL consoles on PREEMPT_RT.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
46/83 [
Author: Sebastian Siewior
Email: bigeasy@linutronix.de
Subject: printk: replace local_irq_save with local_lock for safe mode
Date: Tue, 14 Mar 2023 16:51:44 +0100
Safe mode disables interrupts in order to minimize the window where
printk calls use deferred printing. Currently local_irq_save() is
used for this, however on PREEMPT_RT this can lead to large latencies
because safe mode is enabled for the duration of printing a record.
Use a local_lock instead of local_irq_save(). For !PREEMPT_RT it
has the same affect of disabling interrupts for that CPU. For
PREEMPT_RT it will disable preemption, which is enough to prevent
interruption from the irq threads.
Note that disabling preemption for PREEMPT_RT is also very bad
since it is still blocking RT tasks. The atomic/threaded (NOBKL)
consoles were developed such that safe mode is not needed. So it
is expected that a PREEMPT_RT machine does not run with any legacy
consoles registered.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
47/83 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: serial: 8250: implement non-BKL console
Date: Fri, 3 Mar 2023 12:27:31 +0000
Implement the necessary callbacks to allow the 8250 console driver
to perform as a non-BKL console. Remove the implementation for the
legacy console callback (write) and add implementations for the
non-BKL consoles (write_atomic, write_thread, port_lock) and add
CON_NO_BKL to the initial flags.
Although non-BKL consoles can coexist with legacy consoles, you
will only receive all the benefits of the non-BKL consoles if
this console driver is the only console. That means no netconsole,
no tty1, no earlyprintk, no earlycon. Just the uart8250.
For example: console=ttyS0,115200
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
48/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: printk: Check only for migration in printk_deferred_*().
Date: Fri, 23 Jun 2023 15:58:51 +0200
Atomic context is not required by the implementation. The only
requirement is that the caller does not migrate to another CPU between
the _enter() and _exit() invocation. The reason is to increment and
decrement the per-CPU variable on the same CPU.
Checking for migration only allows to use deferred printk on PREEMPT_RT
when only sleeping locks are acquired.
Check for disabled migration instead for atomic context in
printk_deferred_*()
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
49/83 [
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>
]
50/83 [
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>
]
51/83 [
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>
]
52/83 [
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>
]
53/83 [
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>
]
54/83 [
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>
]
55/83 [
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>
]
56/83 [
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>
]
57/83 [
Author: Tvrtko Ursulin
Email: tvrtko.ursulin@intel.com
Subject: drm/i915: Do not disable preemption for resets
Date: Wed, 5 Jul 2023 10:30:25 +0100
Commit ade8a0f59844 ("drm/i915: Make all GPU resets atomic") added a
preempt disable section over the hardware reset callback to prepare the
driver for being able to reset from atomic contexts.
In retrospect I can see that the work item at a time was about removing
the struct mutex from the reset path. Code base also briefly entertained
the idea of doing the reset under stop_machine in order to serialize
userspace mmap and temporary glitch in the fence registers (see
eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex"),
but that never materialized and was soon removed in 2caffbf11762
("drm/i915: Revoke mmaps and prevent access to fence registers across
reset") and replaced with a SRCU based solution.
As such, as far as I can see, today we still have a requirement that
resets must not sleep (invoked from submission tasklets), but no need to
support invoking them from a truly atomic context.
Given that the preemption section is problematic on RT kernels, since the
uncore lock becomes a sleeping lock and so is invalid in such section,
lets try and remove it. Potential downside is that our short waits on GPU
to complete the reset may get extended if CPU scheduling interferes, but
in practice that probably isn't a deal breaker.
In terms of mechanics, since the preemption disabled block is being
removed we just need to replace a few of the wait_for_atomic macros into
busy looping versions which will work (and not complain) when called from
non-atomic sections.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris.p.wilson@intel.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/r/20230705093025.3689748-1-tvrtko.ursulin@linux.intel.com
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
58/83 [
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>
]
59/83 [
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>
]
60/83 [
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>
]
61/83 [
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>
]
62/83 [
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>
]
63/83 [
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>
]
64/83 [
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>
]
65/83 [
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
]
66/83 [
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>
]
67/83 [
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>
]
68/83 [
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>
]
69/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: vfp: Provide vfp_lock() for VFP locking.
Date: Fri, 19 May 2023 16:57:29 +0200
kernel_neon_begin() uses local_bh_disable() to ensure exclusive access
to the VFP unit. This is broken on PREEMPT_RT because a BH disabled
section remains preemptible on PREEMPT_RT.
Introduce vfp_lock() which uses local_bh_disable() and preempt_disable()
on PREEMPT_RT. Since softirqs are processed always in thread context,
disabling preemption is enough to ensure that the current context won't
get interrupted by something that is using the VFP. Use it in
kernel_neon_begin().
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
70/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: vfp: Use vfp_lock() in vfp_sync_hwstate().
Date: Fri, 19 May 2023 16:57:30 +0200
vfp_sync_hwstate() uses preempt_disable() followed by local_bh_disable()
to ensure that it won't get interrupted while checking the VFP state.
This harms PREEMPT_RT because softirq handling can get preempted and
local_bh_disable() synchronizes the related section with a sleeping lock
which does not work with disabled preemption.
Use the vfp_lock() to synchronize the access.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
71/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: vfp: Use vfp_lock() in vfp_support_entry().
Date: Wed, 28 Jun 2023 09:36:10 +0200
vfp_entry() is invoked from exception handler and is fully preemptible.
It uses local_bh_disable() to remain uninterrupted while checking the
VFP state.
This is not working on PREEMPT_RT because local_bh_disable()
synchronizes the relevant section but the context remains fully
preemptible.
Use vfp_lock() for uninterrupted access.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
72/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: vfp: Move sending signals outside of vfp_lock()ed section.
Date: Wed, 28 Jun 2023 09:39:33 +0200
VFP_bounce() is invoked from within vfp_support_entry() and may send a
signal. Sending a signal uses spinlock_t which becomes a sleeping lock
on PREEMPT_RT and must not be acquired within a preempt-disabled
section.
Move the vfp_raise_sigfpe() block outside of the vfp_lock() section.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
73/83 [
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>
]
74/83 [
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>
]
75/83 [
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>
]
76/83 [
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>
]
77/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: powerpc/imc-pmu: Use the correct spinlock initializer.
Date: Thu, 9 Mar 2023 09:09:01 +0100
The macro __SPIN_LOCK_INITIALIZER() is implementation specific. Users
that desire to initialize a spinlock in a struct must use
__SPIN_LOCK_UNLOCKED().
Use __SPIN_LOCK_UNLOCKED() for the spinlock_t in imc_global_refc.
Fixes: 76d588dddc459 ("powerpc/imc-pmu: Fix use of mutex in IRQs disabled section")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/20230309134831.Nz12nqsU@linutronix.de
]
78/83 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: powerpc/pseries: Select the generic memory allocator.
Date: Thu, 9 Mar 2023 09:13:52 +0100
The RTAS work area allocator is using the generic memory allocator and
as such it must select it.
Select the generic memory allocator on pseries.
Fixes: 43033bc62d349 ("powerpc/pseries: add RTAS work area allocator")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Link: https://lore.kernel.org/20230309135110.uAxhqRFk@linutronix.de
]
79/83 [
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>
]
80/83 [
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>
]
81/83 [
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>
]
82/83 [
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>
]
83/83 [
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>
|
|
When enabled DEBUG_INFO_BTF option, some kernel modules cannot install due to mismatch the
vmlinux BTF header information and output error message as below:
root@intel-x86-64:~# modprobe squashfs
BPF: type_id=12 bits_offset=64
BPF:
BPF: Invalid name
BPF:
failed to validate module [squashfs] BTF: -22
modprobe: ERROR: could not insert 'squashfs': Invalid argument
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
pahole doesn't support all architectures or kernel versions. As such
we don't want config_btf to be enabled for all debug kernels.
Moving it to a separate fragment so it can be enabled only when
needed.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# Conflicts:
# features/debug/debug-kernel.cfg
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: kbuild
Date: Thu, 21 Sep 2023 17:47:14 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: base
Date: Thu, 21 Sep 2023 17:48:58 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
3/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: mmap
Date: Thu, 21 Sep 2023 17:49:39 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
4/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: standalone
Date: Thu, 21 Sep 2023 17:50:11 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
5/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: core
Date: Thu, 21 Sep 2023 17:51:24 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
6/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: adapt to v6.6
Date: Thu, 21 Sep 2023 18:20:40 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
7/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: fix magic.mk include path
Date: Thu, 6 Jul 2023 11:34:59 -0400
commit 482d7131560c51da3ca [aufs stdalone: make it standalone] in the
aufs upstream changes the way that the .mk file is included.
This doesn't work properly with all kernel build processes, so we
restore the use of srctree/src to locate the file.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
8/8 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: aufs6: adapt to v6.6 i_op->ctime changes
Date: Thu, 21 Sep 2023 22:18:30 -0400
The following commits in 6.6+ change the way i_nodes and ctime are
handled. We adapt the code to match:
541d4c798a598854fcce7326d947cbcbd35701d6 [fs: drop the timespec64 arg from generic_update_time]
3e3271549670783be20e233a2b78a87a0b04c715 [vfs: get rid of old '->iterate' directory operation]
0d72b92883c651a11059d93335f33d65c6eb653b [fs: pass the request_mask to generic_fillattr]
913e99287b98fd051ac1976140a2764a8ef9dfbf [fs: drop the timespec64 argument from update_time]
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>
|
|
kernel upstream already removed the CONFIG_F2FS_IO_TRACE[1],
this causes do_kernel_configcheck report warnings:
[INFO]: the following symbols were not found in the active configuration:
- CONFIG_F2FS_IO_TRACE
[1] https://git.kernel.org/linus/d5f7bc00
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.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>
|
|
Fixes do_kernel_configcheck warnings:
WARNING: [kernel config]: This BSP contains fragments with warnings:
[INFO]: Fragments with badly formatted configuration options:
- fragment configs/v6.4/standard/features/wifi/ralink-pci.cfg has the following issues: config RT2800PCI_RT35XX=y
- fragment configs/v6.4/standard/features/wifi/ralink-pci.cfg has the following issues: config RT2800PCI_RT53XX=y
- fragment configs/v6.4/standard/features/wifi/ralink-pci.cfg has the following issues: config RT2800PCI_RT3290=y
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
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/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: yaffs2: v6.5 fixups
Date: Thu, 27 Jul 2023 18:17:32 -0400
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: aufs: v6.5 fixes
Date: Thu, 27 Jul 2023 18:14:23 -0400
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: aufs6: base
Date: Thu, 6 Jul 2023 10:32:11 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
Paul Gortmaker
Khem Raj
Bruce Ashfield
William Lyu
Xiaolei Wang
Yongxin Liu
Liwei Song
Ross Burton
Paul Gortmaker
Meng Li
Xiangyu Chen
Yogesh Tyagi
Anuj Mittal
Naveen Saini
C. Andy Martin
Mikko Rapeli