On 11-07-18 21:17, Steven Rostedt wrote:

From: Steven Rostedt (VMware) <rost...@goodmis.org>

There's been discussion on the fb list about the addition of
WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
the fb module is loaded with lockless_register_fb the console lock is
not taken for debugging reasons. With the addition of
WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to
fill up with warnings when trying to debug the fb driver.

There's also a #if 1 that enables the warning which was added before
git history, and we look down on constant #if's in the kernel nowadays

Remove the #if 1 and add a ignore_console_lock_warning boolean that can
be set by drivers to ignore the warning in order to do debugging.

Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de
Signed-off-by: Steven Rostedt (VMware) <rost...@goodmis.org>

Based on the fbdev discussion this seems a good idea to me
and codewise this looks good to:

Reviewed-by: Hans de Goede <hdego...@redhat.com>



diff --git a/include/linux/console.h b/include/linux/console.h
index dfd6b0e97855..9d4a6b985154 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -200,11 +200,9 @@ void vcs_make_sysfs(int index);
  void vcs_remove_sysfs(int index);
/* Some debug stub to catch some of the obvious races in the VT code */
-#if 1
-#define WARN_CONSOLE_UNLOCKED()        WARN_ON(!is_console_locked() && 
+extern bool ignore_console_lock_warning;
+#define WARN_CONSOLE_UNLOCKED()                                                
+       WARN_ON(!ignore_console_lock_warning && !is_console_locked() && 
/* VESA Blanking Levels */
  #define VESA_NO_BLANKING        0
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 247808333ba4..d9056efc3739 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -66,6 +66,9 @@ int console_printk[4] = {
        CONSOLE_LOGLEVEL_DEFAULT,       /* default_console_loglevel */
+bool ignore_console_lock_warning __read_mostly;
   * Low level drivers may need that to know if they can schedule in
   * their unblank() callback or not. So let's export it.

Reply via email to