From: Petr Mladek <pmladek@suse.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
John Ogness <john.ogness@linutronix.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: "Andy Shevchenko" <andy.shevchenko@gmail.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
"Marco Elver" <elver@google.com>,
"David Laight" <David.Laight@ACULAB.COM>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Paul E . McKenney" <paulmck@kernel.org>,
"Zhouyi Zhou" <zhouzhouyi@gmail.com>,
dave@stgolabs.net, "Josh Triplett" <josh@joshtriplett.org>,
rcu@vger.kernel.org, frederic@kernel.org,
"Marek Behún" <kabel@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH 3/6] Revert "printk: remove @console_locked"
Date: Thu, 23 Jun 2022 16:51:54 +0200 [thread overview]
Message-ID: <20220623145157.21938-4-pmladek@suse.com> (raw)
In-Reply-To: <20220623145157.21938-1-pmladek@suse.com>
This reverts commit ab406816fca009349b89cbde885daf68a8c77e33.
The testing of 5.19 release candidates revealed missing synchronization
between early and regular console functionality.
It would be possible to start the console kthreads later as a workaround.
But it is clear that console lock serialized console drivers between
each other. It opens a big area of possible problems that were not
considered by people involved in the development and review.
printk() is crucial for debugging kernel issues and console output is
very important part of it. The number of consoles is huge and a proper
review would take some time. As a result it need to be reverted for 5.19.
Link: https://lore.kernel.org/r/YrBdjVwBOVgLfHyb@alley
Signed-off-by: Petr Mladek <pmladek@suse.com>
---
kernel/printk/printk.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index ea3dd55709e7..dfd1a19b95d6 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -340,7 +340,15 @@ static void console_kthreads_unblock(void)
console_kthreads_blocked = false;
}
-static int console_suspended;
+/*
+ * This is used for debugging the mess that is the VT code by
+ * keeping track if we have the console semaphore held. It's
+ * definitely not the perfect debug tool (we don't know if _WE_
+ * hold it and are racing, but it helps tracking those weird code
+ * paths in the console code where we end up in places I want
+ * locked without the console semaphore held).
+ */
+static int console_locked, console_suspended;
/*
* Array of consoles built from command line options (console=)
@@ -2711,6 +2719,7 @@ void console_lock(void)
if (console_suspended)
return;
console_kthreads_block();
+ console_locked = 1;
console_may_schedule = 1;
}
EXPORT_SYMBOL(console_lock);
@@ -2735,26 +2744,15 @@ int console_trylock(void)
up_console_sem();
return 0;
}
+ console_locked = 1;
console_may_schedule = 0;
return 1;
}
EXPORT_SYMBOL(console_trylock);
-/*
- * This is used to help to make sure that certain paths within the VT code are
- * running with the console lock held. It is definitely not the perfect debug
- * tool (it is not known if the VT code is the task holding the console lock),
- * but it helps tracking those weird code paths in the console code such as
- * when the console is suspended: where the console is not locked but no
- * console printing may occur.
- *
- * Note: This returns true when the console is suspended but is not locked.
- * This is intentional because the VT code must consider that situation
- * the same as if the console was locked.
- */
int is_console_locked(void)
{
- return (console_kthreads_blocked || atomic_read(&console_kthreads_active));
+ return (console_locked || atomic_read(&console_kthreads_active));
}
EXPORT_SYMBOL(is_console_locked);
@@ -2810,6 +2808,8 @@ static inline bool console_is_usable(struct console *con)
static void __console_unlock(void)
{
+ console_locked = 0;
+
/*
* Depending on whether console_lock() or console_trylock() was used,
* appropriately allow the kthread printers to continue.
@@ -3127,6 +3127,7 @@ void console_unblank(void)
} else
console_lock();
+ console_locked = 1;
console_may_schedule = 0;
for_each_console(c)
if ((c->flags & CON_ENABLED) && c->unblank)
--
2.35.3
next prev parent reply other threads:[~2022-06-23 14:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-23 14:51 [PATCH 0/6] printk: Revert console kthreads for 5.19 Petr Mladek
2022-06-23 14:51 ` [PATCH 1/6] Revert "printk: Wait for the global console lock when the system is going down" Petr Mladek
2022-06-23 14:51 ` [PATCH 2/6] Revert "printk: Block console kthreads when direct printing will be required" Petr Mladek
2022-06-23 14:51 ` Petr Mladek [this message]
2022-06-23 14:51 ` [PATCH 4/6] Revert "printk: extend console_lock for per-console locking" Petr Mladek
2022-06-23 14:51 ` [PATCH 5/6] Revert "printk: add kthread console printers" Petr Mladek
2022-06-23 14:51 ` [PATCH 6/6] Revert "printk: add functions to prefer direct printing" Petr Mladek
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220623145157.21938-4-pmladek@suse.com \
--to=pmladek@suse.com \
--cc=David.Laight@ACULAB.COM \
--cc=Jason@zx2c4.com \
--cc=andy.shevchenko@gmail.com \
--cc=dave@stgolabs.net \
--cc=elver@google.com \
--cc=frederic@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=john.ogness@linutronix.de \
--cc=josh@joshtriplett.org \
--cc=kabel@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=torvalds@linux-foundation.org \
--cc=zhouzhouyi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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