kernel/printk/printk.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
printk might be invoked in a context with disabled interrupts and or
preemption and additionally disables interrupts before it invokes the
console drivers. This behaviour is not desired on PREEMPT_RT:
- The console driver are using spinlock_t based locking which become sleeping
locks on PREEMPT_RT and must not be acquired with disabled interrupts (or
preemption).
- The locks within the console drivers must remain sleeping locks and they must
not disable interrupts. Printing (and polling for its completion) at 115200
baud on an UART takes too long for PREEMPT_RT in general and so raises the
latency of the IRQ-off time of the system beyond acceptable levels.
Skip printing to the console as temporary workaround until the printing threads
and atomic consoles have been introduced or another solution which is
compatible with the PREEMPT_RT approach.
With this change, the user will not see any kernel message printed to the
console but can retrieve the printk buffer from userland (via the dmesg
command). This allows enable PREEMPT_RT as a whole without disabling printk and
loosing all kernel output.
Disable console printing on PREEMPT_RT.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
v2…v3:
- Reword commit message by adding a few details/ explanations.
v1…v2:
- Use __console_unlock() as suggested by John.
kernel/printk/printk.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2843,6 +2843,16 @@ void console_unlock(void)
}
/*
+ * On PREEMPT_RT it is not possible to invoke console drivers with
+ * disabled interrupts and or preemption. Therefore all drivers are
+ * skipped and the output can be retrieved from the buffer.
+ */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
+ __console_unlock();
+ return;
+ }
+
+ /*
* Console drivers are called with interrupts disabled, so
* @console_may_schedule should be cleared before; however, we may
* end up dumping a lot of lines, for example, if called from
On 2022-07-25, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > printk might be invoked in a context with disabled interrupts and or > preemption and additionally disables interrupts before it invokes the > console drivers. This behaviour is not desired on PREEMPT_RT: > - The console driver are using spinlock_t based locking which become sleeping > locks on PREEMPT_RT and must not be acquired with disabled interrupts (or > preemption). > > - The locks within the console drivers must remain sleeping locks and they must > not disable interrupts. Printing (and polling for its completion) at 115200 > baud on an UART takes too long for PREEMPT_RT in general and so raises the > latency of the IRQ-off time of the system beyond acceptable levels. > > Skip printing to the console as temporary workaround until the printing threads > and atomic consoles have been introduced or another solution which is > compatible with the PREEMPT_RT approach. > With this change, the user will not see any kernel message printed to the > console but can retrieve the printk buffer from userland (via the dmesg > command). This allows enable PREEMPT_RT as a whole without disabling printk and > loosing all kernel output. Note that "the dmesg command" is not the only userspace tool to access the kernel logs. Logging daemons (using /proc/kmsg or /dev/kmsg) also have full access. > Disable console printing on PREEMPT_RT. > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: John Ogness <john.ogness@linutronix.de>
On Tue 2022-07-26 10:03:39, John Ogness wrote: > On 2022-07-25, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > printk might be invoked in a context with disabled interrupts and or > > preemption and additionally disables interrupts before it invokes the > > console drivers. This behaviour is not desired on PREEMPT_RT: > > - The console driver are using spinlock_t based locking which become sleeping > > locks on PREEMPT_RT and must not be acquired with disabled interrupts (or > > preemption). > > > > - The locks within the console drivers must remain sleeping locks and they must > > not disable interrupts. Printing (and polling for its completion) at 115200 > > baud on an UART takes too long for PREEMPT_RT in general and so raises the > > latency of the IRQ-off time of the system beyond acceptable levels. > > > > Skip printing to the console as temporary workaround until the printing threads > > and atomic consoles have been introduced or another solution which is > > compatible with the PREEMPT_RT approach. > > With this change, the user will not see any kernel message printed to the > > console but can retrieve the printk buffer from userland (via the dmesg > > command). This allows enable PREEMPT_RT as a whole without disabling printk and > > loosing all kernel output. > > Note that "the dmesg command" is not the only userspace tool to access > the kernel logs. Logging daemons (using /proc/kmsg or /dev/kmsg) also > have full access. I have updated the message when comitting, see https://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git/commit/?h=rework/kthreads&id=c01c1c784a02aaa216524977b294b8834d0ee907 > > Disable console printing on PREEMPT_RT. > > > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > > Reviewed-by: John Ogness <john.ogness@linutronix.de> JFYI, the patch has been committed into printk/linux.git, branch rework/kthreads. I am going to add it into the pull request for 5.20. Best Regards, Petr
On Mon 2022-07-25 17:16:16, Sebastian Andrzej Siewior wrote: > printk might be invoked in a context with disabled interrupts and or > preemption and additionally disables interrupts before it invokes the > console drivers. This behaviour is not desired on PREEMPT_RT: > - The console driver are using spinlock_t based locking which become sleeping > locks on PREEMPT_RT and must not be acquired with disabled interrupts (or > preemption). > > - The locks within the console drivers must remain sleeping locks and they must > not disable interrupts. Printing (and polling for its completion) at 115200 > baud on an UART takes too long for PREEMPT_RT in general and so raises the > latency of the IRQ-off time of the system beyond acceptable levels. > > Skip printing to the console as temporary workaround until the printing threads > and atomic consoles have been introduced or another solution which is > compatible with the PREEMPT_RT approach. > With this change, the user will not see any kernel message printed to the > console but can retrieve the printk buffer from userland (via the dmesg > command). This allows enable PREEMPT_RT as a whole without disabling printk and > loosing all kernel output. > > Disable console printing on PREEMPT_RT. > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Thanks a lot for updating the commit message. It looks good to me now. Reviewed-by: Petr Mladek <pmladek@suse.com> Best Regards, Petr PS: John, if you ack it then I'll queue it for 5.20.
© 2016 - 2025 Red Hat, Inc.