Age | Commit message (Collapse) | Author |
|
Backported from commit on branch "yocto-6.6":
70cabea69443e974db04d6dcbe73031d0d726bc1
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>
|
|
Backported from commit on branch "yocto-6.6":
40ecdcc5e4f5053536cec6e3f74334aa418f07cc
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 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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Layers in yocto ecosystem are adding a security file to
document how CVEs and other security issues should be
handled.
The kernel-cache doesn't specifically have executable
code, but it could have configuration options that lead
to security issues, so we document the process if that
happens.
This also renames the README file to a more common
name.
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>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.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/1 [
Author: Richard Purdie
Email: richard.purdie@linuxfoundation.org
Subject: serial-core: disable power managment for serial tx
Date: Mon, 16 Oct 2023 07:44:55 -0400
1% of the time where the getty never appears on ttyS1 even after our
timeout of 1000s.
When this happens we've added code to login to the ttyS0 getty and run
debug commands. We've been able to confirm the getty is running and the
init system doesn't matter (happens with sysvinit and systemd). The
most interesting debug I've seen is this:
root@qemux86-64:~# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:418 rx:43 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:000002F8 irq:3 tx:249 rx:0 RTS|CTS|DTR|DSR|CD
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
root@qemux86-64:~# echo helloA > /dev/ttyS1
root@qemux86-64:~# echo helloB > /dev/ttyS0
helloB
root@qemux86-64:~# cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:803 rx:121 RTS|CTS|DTR|DSR|CD
1: uart:16550A port:000002F8 irq:3 tx:281 rx:0 RTS|CTS|DTR|DSR|CD
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
This is being run after the getty didn't appear for 60s on ttyS1 so
we've logged into ttyS0 and run these commands. We've seen that if it
doesn't appear after 60s, it won't appear after 1000s either.
The tx:249 is interesting as it should be tx:273, 273 being the number
of bytes our successful serial getty prompt has. Once we echo something
to the port (8 bytes), tx: jumps to 281, so it suddenly found our
missing login prompt. This is confirmed with the data appearing on the
port after the echo.
I did try disabling the autosuspend code in the commit above but it
made no difference. What does seem to help is changing the conditional
the patch adds around start_tx() back to being under the original
conditions. This is relatively harmless as it will just stop_tx() again
if the xmit buffer is empty and this is a one off operation at probe
time.
The small overhead is much preferred to randomly failing tests.
Discussions with upstream are being attempted:
https://lore.kernel.org/linux-serial/c85ab969826989c27402711155ec086fd81574fb.camel@linuxfoundation.org/T/#t
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.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>
|
|
As of the v6.1 kernel, ARM_PATCH_PHYS_VIRT is no longer being enabled by
default. This is causing poky-tiny to not boot (as it automatically
disables all features not explicitly enabled).
Signed-off-by: Jon Mason <jdmason@kudzu.us>
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: mips: make current_cpu_data preempt safe
Date: Fri, 29 Sep 2023 00:11:41 +0000
When DEBUG_PREEMPT is enabled, mips/mips64 boots are filled with
backtraces similar to:
[ 130.730686] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 130.738542] caller is blast_dcache32+0x40/0x190
[ 130.745908] CPU: 0 PID: 1 Comm: systemd Not tainted 6.4.11-yocto-standard #1
[ 130.753928] Stack : 0000000000000001 0000000000000000 0000000000000018 9000000004937798
[ 130.762192] 9000000004937798 90000000049378c8 0000000000000000 0000000000000000
[ 130.770458] 008fac6060240fea 0000000000014f20 9000000004937728 0000000000000000
[ 130.778826] 00000000000b61b4 0000000000000030 ffffffff80e8eed0 0000000000000004
[ 130.787111] 9000000084937577 0000000000000000 0000000000000000 ffffffff810c3b18
[ 130.795440] ffffffff811f0000 0000000000000000 ffffffff81440000 0000000000000000
[ 130.803830] 0000000000000000 0000000000000000 ffffffff809842e8 0000000000175097
[ 130.812272] 0000000000000001 9000000004934000 9000000004937790 c0000000005d9000
[ 130.820722] ffffffff8010b6fc 0000000000000000 0000000000000000 0000000000000000
[ 130.829134] 0000000000000000 0000000000000000 ffffffff8010b71c 008fac6060240fea
[ 130.837649] ...
[ 130.845556] Call Trace:
[ 130.853432] [<ffffffff8010b71c>] show_stack+0x64/0x158
[ 130.861534] [<ffffffff80ea1790>] dump_stack_lvl+0x5c/0x7c
[ 130.869565] [<ffffffff80ea29c4>] check_preemption_disabled+0x10c/0x118
[ 130.877605] [<ffffffff8012d7c8>] blast_dcache32+0x40/0x190
[ 130.885585] [<ffffffff8039f648>] __vmalloc_node_range+0x3e0/0x780
[ 130.893527] [<ffffffff8039fbbc>] vzalloc+0x6c/0x78
[ 130.901378] [<ffffffff8095d6c4>] n_tty_open+0x1c/0xb8
[ 130.909252] [<ffffffff8095f5a8>] tty_ldisc_open+0x50/0xd0
[ 130.917053] [<ffffffff80960150>] tty_ldisc_setup+0x20/0x70
[ 130.924927] [<ffffffff80958694>] tty_init_dev.part.0+0xbc/0x2c0
[ 130.932742] [<ffffffff80958da8>] tty_open+0x4b8/0x730
[ 130.940486] [<ffffffff803e6960>] chrdev_open+0xe0/0x250
[ 130.948211] [<ffffffff803da7f4>] do_dentry_open+0x274/0x520
[ 130.955960] [<ffffffff803f642c>] path_openat+0xbc4/0x10d8
[ 130.963718] [<ffffffff803f7460>] do_filp_open+0x148/0x190
[ 130.971482] [<ffffffff803dc264>] do_sys_openat2+0xcc/0x1b0
[ 130.979288] [<ffffffff803dc710>] sys_openat+0x50/0xa8
[ 130.987077] [<ffffffff80119490>] syscall_common+0x34/0x58
We don't control the locking around current_cpu_data, so it cannot use
smp_processor_id() as the cpu index.
To make ourselves safe in any context, we must use raw_smp_processor_id()
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>
|
|
1/87 [
Author: Wander Lairson Costa
Email: wander@redhat.com
Subject: sched: avoid false lockdep splat in put_task_struct()
Date: Wed, 14 Jun 2023 09:23:22 -0300
In put_task_struct(), a spin_lock is indirectly acquired under the kernel
stock. When running the kernel in real-time (RT) configuration, the
operation is dispatched to a preemptible context call to ensure
guaranteed preemption. However, if PROVE_RAW_LOCK_NESTING is enabled
and __put_task_struct() is called while holding a raw_spinlock, lockdep
incorrectly reports an "Invalid lock context" in the stock kernel.
This false splat occurs because lockdep is unaware of the different
route taken under RT. To address this issue, override the inner wait
type to prevent the false lockdep splat.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Luis Goncalves <lgoncalv@redhat.com>
Link: https://lore.kernel.org/r/20230614122323.37957-3-wander@redhat.com
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
2/87 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: sched: Constrain locks in sched_submit_work()
Date: Tue, 15 Aug 2023 13:01:22 +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>
Link: https://lore.kernel.org/r/20230815111430.154558666@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
3/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: Avoid unconditional slowpath for DEBUG_RT_MUTEXES
Date: Tue, 15 Aug 2023 13:01:23 +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: 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/20230427111937.2745231-4-bigeasy@linutronix.de
Link: https://lore.kernel.org/r/20230815111430.220899937@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
4/87 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: sched: Extract __schedule_loop()
Date: Tue, 15 Aug 2023 13:01:24 +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: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230427111937.2745231-2-bigeasy@linutronix.de
Link: https://lore.kernel.org/r/20230815111430.288063671@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
5/87 [
Author: Peter Zijlstra
Email: peterz@infradead.org
Subject: sched: Provide rt_mutex specific scheduler helpers
Date: Tue, 15 Aug 2023 13:01:25 +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>
Link: https://lore.kernel.org/r/20230815111430.355375399@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
6/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: Use rt_mutex specific scheduler helpers
Date: Tue, 15 Aug 2023 13:01:26 +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: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Link: https://lore.kernel.org/r/20230815111430.421408298@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
7/87 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: locking/rtmutex: Add a lockdep assert to catch potential nested blocking
Date: Tue, 15 Aug 2023 13:01:27 +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>
Link: https://lkml.kernel.org/r/20230427111937.2745231-5-bigeasy@linutronix.de
Link: https://lore.kernel.org/r/20230815111430.488430699@infradead.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
8/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: locking/rtmutex: Acquire the hb lock via trylock after wait-proxylock.
Date: Thu, 31 Aug 2023 11:53:14 +0200
After rt_mutex_wait_proxy_lock() task_struct::pi_blocked_on is cleared
if current owns the lock. If the operation has been interrupted by a
signal or timeout then pi_blocked_on can be set. This means spin_lock()
*can* overwrite pi_blocked_on on PREEMPT_RT. This has been noticed by
the recently added lockdep-asserts…
The rt_mutex_cleanup_proxy_lock() operation will clear pi_blocked_on
(and update pending waiters as expected) but it must happen under the hb
lock to ensure the same state in rtmutex and userland.
Given all the possibilities it is probably the simplest option to
try-lock the hb lock. In case the lock is occupied a quick nap is
needed. A busy loop can lock up the system if performed by a task with
high priorioty preventing the owner from running.
The rt_mutex_post_schedule() needs to be put before try-lock-loop
because otherwie the schedule() in schedule_hrtimeout() will trip over
the !sched_rt_mutex assert.
Introduce futex_trylock_hblock() to try-lock the hb lock and sleep until
the try-lock operation succeeds. Use it after rt_mutex_wait_proxy_lock()
to acquire the lock.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230831095314.fTliy0Bh@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
9/87 [
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
]
10/87 [
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
]
11/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: seqlock: Do the lockdep annotation before locking in do_write_seqcount_begin_nested()
Date: Fri, 23 Jun 2023 19:12:31 +0200
It was brought up by Tetsuo that the following sequence
write_seqlock_irqsave()
printk_deferred_enter()
could lead to a deadlock if the lockdep annotation within
write_seqlock_irqsave() triggers. The problem is that the sequence
counter is incremented before the lockdep annotation is performed. The
lockdep splat would then attempt to invoke printk() but the reader side,
of the same seqcount, could have a tty_port::lock acquired waiting for
the sequence number to become even again.
The other lockdep annotations come before the actual locking because "we
want to see the locking error before it happens". There is no reason why
seqcount should be different here.
Do the lockdep annotation first then perform the locking operation (the
sequence increment).
Fixes: 1ca7d67cf5d5a ("seqcount: Add lockdep functionality to seqcount/seqlock structures")
Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/20230621130641.-5iueY1I@linutronix.de
Link: https://lore.kernel.org/r/20230623171232.892937-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
12/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save().
Date: Fri, 23 Jun 2023 22:15:17 +0200
__build_all_zonelists() acquires zonelist_update_seq by first disabling
interrupts via local_irq_save() and then acquiring the seqlock with
write_seqlock(). This is troublesome and leads to problems on
PREEMPT_RT. The problem is that the inner spinlock_t becomes a sleeping
lock on PREEMPT_RT and must not be acquired with disabled interrupts.
The API provides write_seqlock_irqsave() which does the right thing in
one step.
printk_deferred_enter() has to be invoked in non-migrate-able context to
ensure that deferred printing is enabled and disabled on the same CPU.
This is the case after zonelist_update_seq has been acquired.
There was discussion on the first submission that the order should be:
local_irq_disable();
printk_deferred_enter();
write_seqlock();
to avoid pitfalls like having an unaccounted printk() coming from
write_seqlock_irqsave() before printk_deferred_enter() is invoked. The
only origin of such a printk() can be a lockdep splat because the
lockdep annotation happens after the sequence count is incremented.
This is exceptional and subject to change.
It was also pointed that PREEMPT_RT can be affected by the printk
problem since its write_seqlock_irqsave() does not really disable
interrupts. This isn't the case because PREEMPT_RT's printk
implementation differs from the mainline implementation in two important
aspects:
- Printing happens in a dedicated threads and not at during the
invocation of printk().
- In emergency cases where synchronous printing is used, a different
driver is used which does not use tty_port::lock.
Acquire zonelist_update_seq with write_seqlock_irqsave() and then defer
printk output.
Fixes: 1007843a91909 ("mm/page_alloc: fix potential deadlock on zonelist_update_seq seqlock")
Acked-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20230623201517.yw286Knb@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
13/87 [
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>
]
14/87 [
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>
]
15/87 [
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>
]
16/87 [
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>
]
17/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: x86/microcode: Remove microcode_mutex.
Date: Fri, 4 Aug 2023 09:58:53 +0200
microcode_mutex is only used by reload_store(). It has a comment saying
"to synchronize with each other". Other user of this mutex have been
removed in the commits
181b6f40e9ea8 ("x86/microcode: Rip out the OLD_INTERFACE").
b6f86689d5b74 ("x86/microcode: Rip out the subsys interface gunk")
The sysfs interface does not need additional synchronisation vs itself
because it is provided as kernfs_ops::mutex which is acquired in
kernfs_fop_write_iter().
Remove superfluous microcode_mutex.
Link: https://lore.kernel.org/r/20230803083253.VGMnC9Gd@linutronix.de
Link: https://lore.kernel.org/r/20230804075853.JF_n6GXC@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
18/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ASoC: mediatek: mt8186: Remove unused mutex.
Date: Thu, 3 Aug 2023 10:39:08 +0200
The mutex mutex_request_dram has no user.
Remove mutex_request_dram.
Link: https://lore.kernel.org/r/20230803083908.9DxbPvOK@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
19/87 [
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/87 [
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/87 [
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/87 [
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/87 [
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/87 [
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/87 [
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/87 [
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/87 [
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/87 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: kdb: do not assume write() callback available
Date: Fri, 24 Feb 2023 15:23:51 +0000
It is allowed for consoles to provide no write() callback. For
example ttynull does this.
Check if a write() callback is available before using it.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
29/87 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: Add NMI check to console_flush_on_panic() and console_unblank()
Date: Fri, 30 Dec 2022 15:49:42 +0106
The printk path is NMI safe because it only adds content to the
buffer and then triggers the delayed output via irq_work. If the
console is flushed or unblanked on panic (from NMI context) then it
can deadlock in down_trylock_console_sem() because the semaphore is
not NMI safe.
Avoid taking the console_lock when flushing in panic and the current
context is NMI. Since the consoles are encouraged to ignore their
locks and also will stop printing if not the panic CPU, this change
does not really make things any more dangerous. But it does avoid
a possible deadlock in NMI context.
Skip unblanking in panic if the current context is NMI.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
30/87 [
Author: John Ogness
Email: john.ogness@linutronix.de
Subject: printk: Add per-console suspended state
Date: Fri, 17 Feb 2023 15:43:37 +0000
Currently the global @console_suspended is used to determine if
consoles are in a suspended state. Its primary purpose is to allow
usage of the console_lock when suspended without causing console
printing. It is synchronized by the console_lock.
Rather than relying on the console_lock to determine suspended
state, make it an official per-console state that is set within
console->flags. This allows the state to be queried via SRCU.
@console_suspended will continue to exist, but now only to implement
the console_lock/console_unlock trickery and _not_ to represent
the suspend state of a particular console.
Signed-off-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
31/87 [
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>
]
32/87 [
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>
]
33/87 [
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>
]
34/87 [
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>
]
35/87 [
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>
]
36/87 [
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>
]
37/87 [
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>
]
38/87 [
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>
]
39/87 [
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>
]
40/87 [
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>
]
41/87 [
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>
]
42/87 [
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>
]
43/87 [
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>
]
44/87 [
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>
]
45/87 [
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>
]
46/87 [
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>
]
47/87 [
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>
]
48/87 [
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>
]
49/87 [
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>
]
50/87 [
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>
]
51/87 [
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>
]
52/87 [
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>
]
53/87 [
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>
]
54/87 [
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>
]
55/87 [
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>
]
56/87 [
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>
]
57/87 [
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>
]
58/87 [
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>
]
59/87 [
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>
]
60/87 [
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>
]
61/87 [
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>
]
62/87 [
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>
]
63/87 [
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>
]
64/87 [
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>
]
65/87 [
Author: Thomas Gleixner
Email: tglx@linutronix.de
Subject: entry: Fix the preempt lazy fallout
Date: Tue, 13 Jul 2021 07:52:52 +0200
Common code needs common defines....
Fixes: f2f9e496208c ("x86: Support for lazy preemption")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
]
66/87 [
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>
]
67/87 [
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>
]
68/87 [
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>
]
69/87 [
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
]
70/87 [
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>
]
71/87 [
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>
]
72/87 [
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>
]
73/87 [
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().
Link: https://lore.kernel.org/r/20230519145731.574867-2-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
74/87 [
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.
Link: https://lore.kernel.org/r/20230519145731.574867-3-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
75/87 [
Author: Sebastian Andrzej Siewior
Email: bigeasy@linutronix.de
Subject: ARM: vfp: Use vfp_lock() in vfp_entry().
Date: Fri, 19 May 2023 16:57:31 +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.
VFP_bounce() is invoked from within vfp_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
preempt-disabled section.
Link: https://lore.kernel.org/r/20230519145731.574867-4-bigeasy@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
]
76/87 [
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>
]
77/87 [
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>
]
78/87 [
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>
]
79/87 [
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>
]
80/87 [
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
]
81/87 [
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
]
82/87 [
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>
]
83/87 [
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>
]
84/87 [
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>
]
85/87 [
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>
]
86/87 [
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>
]
87/87 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: rt/printk: synchronize merge with v6.6-printk
Date: Wed, 27 Sep 2023 09:20:01 -0400
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
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
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: yaffs2: replace iterate with iterate_shared
Date: Tue, 26 Sep 2023 20:48:57 -0400
The directory iteration in kernel v6.5.x should use the .iterate_shared
structure assignment.
In 6.6.x this changes to .iterate
We adjust our assignment to fix the build.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Upstream commit 1f2190d6b71 [arch/*/configs/*defconfig: Replace
AUTOFS4_FS by AUTOFS_FS]
Has completed the migration to a non-versioned config, we update
our fragments to match.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Due to kernel commit 41ef3c1a6bb0 ("pinctrl: Don't allow PINCTRL_AMD to
be a module"), driver PINCTRL_AMD can only be built as built-in driver
or disabled.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
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>
|
|
This patch hasn't merged upstream yet, so we need to carry it in
the kernel-cache to ensure that any new kernel's have the fix.
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>
|
|
OABI_COMPAT is a backwards compatibility tool intended to support
the old Linux ARM ABI. When the OABI_COMPAT enabled on ARM platform,
the HAVE_ARCH_AUDITSYSCALL[1] and HAVE_ARCH_SECCOMP_FILTER[2] would
be dropped due to those features only support EABI mode.
With strace we can observe that if HAVE_ARCH_AUDITSYSCALL disabled,
the audit tool in userspace would fail to use syscall and report an
error:
strace auditctl -R /etc/audit/audit.rules
sendto(3, [{nlmsg_len=1072, nlmsg_type=0x3f3 /* NLMSG_??? */,
nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=10, nlmsg_pid=0},
"\x04\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x80\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00"...],
1072, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 1072
poll([{fd=3, events=POLLIN}], 1, 500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, [{nlmsg_len=1092, nlmsg_type=NLMSG_ERROR, nlmsg_flags=0,
nlmsg_seq=10, nlmsg_pid=529}, {error=-EINVAL, msg=[{nlmsg_len=1072,
nlmsg_type=0x3f3 /* NLMSG_??? */, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK,
nlmsg_seq=10, nlmsg_pid=0},
"\x04\x00\x00\x00\x02\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x80\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00"...]}],
8988, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, nl_pid=0,
nl_groups=00000000}, [12]) = 1092
write(2, "Error sending add rule data requ"..., 54Error sending add rule
data request (Invalid argument)) = 54
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a017721
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=91702175
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Like the other -tiny BSPs, we need to explicitly include our
HID fragment to ensure that configuration audit warnings are
not thrown as HID will be disabled due to missing dependencies.
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Need igc driver to mount network filesystem.
Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Following commit marked GPIO LED trigger driver 'broken'from 6.4 onward
https://github.com/torvalds/linux/commit/8f0adae1cb1a3cf83e38dd435831baa38dd84b4c
Having CONFIG_LEDS_TRIGGER_GPIO enabled by default is causing below warning during build:
WARNING: linux-intel-6.4.0+gitAUTOINC+de40822021_9bcda79692-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:
[NOTE]: 'CONFIG_LEDS_TRIGGER_GPIO' last val (y) and .config val (n) do not match
[INFO]: CONFIG_LEDS_TRIGGER_GPIO : n
[INFO]: raw config text:
config LEDS_TRIGGER_GPIO
tristate "LED GPIO Trigger"
depends on (GPIOLIB || COMPILE_TEST) && BROKEN && LEDS_TRIGGERS && NEW_LEDS
help
This allows LEDs to be controlled by gpio events. It's good
when using gpios as switches and triggering the needed LEDs
from there. One use case is n810's keypad LEDs that could
be triggered by this trigger when user slides up to show
keypad.
If unsure, say N.
Config 'LEDS_TRIGGER_GPIO' has the following Direct dependencies (LEDS_TRIGGER_GPIO=n):
GPIOLIB(=y) || COMPILE_TEST(=n) (=y) && BROKEN(=n) && LEDS_TRIGGERS(=y) && NEW_LEDS(=y)
Parent dependencies are:
BROKEN [n] LEDS_TRIGGERS [y] COMPILE_TEST [n] GPIOLIB [y] NEW_LEDS [y]
[INFO]: config 'CONFIG_LEDS_TRIGGER_GPIO' was set, but it wasn't assignable, check (parent) dependencies
So let's not enable it by default.
Signed-off-by: Yogesh Tyagi <yogesh.tyagi@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Since tmpfs is supported by preempt-rt, it is better to have
tmpfs-posix-acl feature.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
1/1 [
Author: Bruce Ashfield
Email: bruce.ashfield@gmail.com
Subject: mconf: fix output of cflags and libraries
Date: Mon, 17 Jul 2023 17:17:55 -0400
commit 3122c84409d578a5df8bcb1 [kconfig: refactor Makefile to reduce
process forks] changes the way that flags are detected. They are
no longer just echo'd and captured, they are written to a file and
later read.
We adjust our CROSS ncurses patch accordingly.
We'll eventually be able to drop this patch, but not quite yet.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
This is dropping executable bits, and breaking menuconfig in
6.4+
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
HID is no longer selected, so to avoid -tiny warnings we need to
explicitly enable it in more -tiny BSPs.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|