Commit 87f2e4b7 authored by John Ogness's avatar John Ogness Committed by Petr Mladek

printk: console_flush_on_panic: use srcu console list iterator

With SRCU it is now safe to traverse the console list, even if
the console_trylock() failed. However, overwriting console->seq
when console_trylock() failed is still an issue.

Switch to SRCU iteration and document remaining issue with
console->seq.
Signed-off-by: default avatarJohn Ogness <john.ogness@linutronix.de>
Reviewed-by: default avatarPetr Mladek <pmladek@suse.com>
Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20221116162152.193147-20-john.ogness@linutronix.de
parent d792db6f
......@@ -3050,22 +3050,23 @@ void console_flush_on_panic(enum con_flush_mode mode)
console_may_schedule = 0;
if (mode == CONSOLE_REPLAY_ALL) {
struct hlist_node *tmp;
struct console *c;
int cookie;
u64 seq;
seq = prb_first_valid_seq(prb);
cookie = console_srcu_read_lock();
for_each_console_srcu(c) {
/*
* This cannot use for_each_console() because it's not established
* that the current context has console locked and neither there is
* a guarantee that there is no concurrency in that case.
*
* Open code it for documentation purposes and pretend that
* it works.
* If the above console_trylock() failed, this is an
* unsynchronized assignment. But in that case, the
* kernel is in "hope and pray" mode anyway.
*/
hlist_for_each_entry_safe(c, tmp, &console_list, node)
c->seq = seq;
}
console_srcu_read_unlock(cookie);
}
console_unlock();
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment