From: Petr Mladek <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>
Cc: Sergey Senozhatsky <firstname.lastname@example.org>,
Steven Rostedt <email@example.com>,
John Ogness <firstname.lastname@example.org>,
Andy Shevchenko <email@example.com>,
Rasmus Villemoes <firstname.lastname@example.org>,
Jan Kara <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>,
Subject: [GIT PULL] printk for 5.19
Date: Mon, 23 May 2022 15:21:07 +0200 [thread overview]
Message-ID: <YouKQw72H7y9EJQK@alley> (raw)
please pull the latest printk changes from
- Offload writing printk() messages on consoles to per-console kthreads.
It prevents soft-lockups when an extensive amount of messages is printed.
It was observed, for example, during boot of large systems with a lot
of peripherals like disks or network interfaces.
It prevents live-lockups that were observed, for example, when messages
about allocation failures were reported and a CPU handled consoles
instead of reclaiming the memory. It was hard to solve even with
rate limiting because it would need to take into account the amount
of messages and the speed of all consoles.
It is a must to have for real time. Otherwise, any printk() might break
The per-console kthreads allow to handle each console on its own speed.
Slow consoles do not longer slow down faster ones. And printk() does
not longer unpredictably slows down various code paths.
There are situations when the kthreads are either not available or
not reliable, for example, early boot, suspend, or panic. In these
situations, printk() uses the legacy mode and tries to handle consoles
- Add documentation for the printk index.
There was always fear that messages might not reach the console when
the kthreads could not be scheduled. It blocked introducing the kthreads
for nearly a decade.
It is clear that the kthreads adds some risk that the messages will
not reach consoles. But the original solution was just the best
The kthreads fix some real bugs as mentioned above. Also they allow
to see the messages on other consoles when other consoles are slow
or get stuck.
The patchset has been in linux-next for nearly one month since April 26.
It helped to find one already existing race when initializing
a console device. It made the race more visible, see
Nobody reported problems with missing messages. Of course, it just
a good sign but it is not proof of anything. Let's see how it
works when it gets more testing in the mainline. I am afraid
that we won't find without trying.
Chris Down (1):
MAINTAINERS: Add printk indexing maintainers on mention of printk_index
John Ogness (15):
printk: rename cpulock functions
printk: cpu sync always disable interrupts
printk: add missing memory barrier to wake_up_klogd()
printk: wake up all waiters
printk: wake waiters for safe and NMI contexts
printk: get caller_id/timestamp after migration disable
printk: call boot_delay_msec() in printk_delay()
printk: add con_printk() macro for console details
printk: refactor and rework printing logic
printk: move buffer definitions into console_emit_next_record() caller
printk: add pr_flush()
printk: add functions to prefer direct printing
printk: add kthread console printers
printk: extend console_lock for per-console locking
printk: remove @console_locked
Marco Elver (1):
printk, tracing: fix console tracepoint
Petr Mladek (2):
printk/index: Printk index feature documentation
Merge branch 'rework/kthreads' into for-linus
Documentation/core-api/index.rst | 1 +
Documentation/core-api/printk-index.rst | 137 ++++
MAINTAINERS | 2 +
drivers/tty/sysrq.c | 2 +
include/linux/console.h | 19 +
include/linux/printk.h | 82 ++-
kernel/hung_task.c | 11 +-
kernel/panic.c | 4 +
kernel/printk/printk.c | 1205 +++++++++++++++++++++++--------
kernel/rcu/tree_stall.h | 2 +
kernel/reboot.c | 14 +-
kernel/watchdog.c | 4 +
kernel/watchdog_hld.c | 4 +
lib/dump_stack.c | 4 +-
lib/nmi_backtrace.c | 4 +-
15 files changed, 1174 insertions(+), 321 deletions(-)
create mode 100644 Documentation/core-api/printk-index.rst
next reply other threads:[~2022-05-23 13:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 13:21 Petr Mladek [this message]
2022-05-25 18:09 ` [GIT PULL] printk for 5.19 Linus Torvalds
2022-05-25 22:02 ` John Ogness
2022-05-26 12:09 ` Petr Mladek
2022-05-26 17:13 ` Linus Torvalds
2022-05-25 18:37 ` pr-tracker-bot
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).