lkml.org 
[lkml]   [2006]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject[patch] turn on might_sleep() in early bootup code too

Could we try the patch below in -mm, to get a feeling of how widespread
the early bootup lock-atomicity assumptions are? I also added a .config
option to add back the workaround, and turned it on for ppc64. (users
can still select this manually on any other arch as well)

i found one such bug on x86: early-printk calls register_console(),
which acquires console_sem. Since we can work such things around
per-lock and per-assumption [see the printk.c changes], i think we
should rather do the workarounds that way, and thus document the hacks
we need - without impacting the ability of such platforms to boot -
while still keeping might_sleep() checks widely enabled. (btw., x86
still booted fine, despite the warning.)

Ingo

--

enable might_sleep() checks even in early bootup code (when system_state
!= SYSTEM_RUNNING). There's also a new config option to turn this off:
CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
while most other architectures.

the patch also documents and works around an EARLY_PRINTK locking
dependency. [which we might want to get rid of in the future.]

tested on x86.

Signed-off-by: Ingo Molnar <mingo@elte.hu>

----

arch/powerpc/Kconfig.debug | 2 ++
kernel/printk.c | 11 ++++++++++-
kernel/sched.c | 7 +++++--
lib/Kconfig.debug | 11 +++++++++++
4 files changed, 28 insertions(+), 3 deletions(-)

Index: linux/arch/powerpc/Kconfig.debug
===================================================================
--- linux.orig/arch/powerpc/Kconfig.debug
+++ linux/arch/powerpc/Kconfig.debug
@@ -2,6 +2,8 @@ menu "Kernel hacking"

source "lib/Kconfig.debug"

+select CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+
config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL && PPC64
Index: linux/kernel/printk.c
===================================================================
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -710,7 +710,16 @@ void acquire_console_sem(void)
{
if (in_interrupt())
BUG();
- down(&console_sem);
+ /*
+ * Early-printk wants to acquire the console_sem in
+ * register_console(). Make a special exception for them by
+ * going via trylock first, which doesnt trigger the
+ * might_sleep() atomicity check.
+ */
+#ifdef CONFIG_EARLY_PRINTK
+ if (down_trylock(&console_sem))
+#endif
+ down(&console_sem);
console_locked = 1;
console_may_schedule = 1;
}
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -6285,8 +6285,11 @@ void __might_sleep(char *file, int line)
#if defined(in_atomic)
static unsigned long prev_jiffy; /* ratelimiting */

- if ((in_atomic() || irqs_disabled()) &&
- system_state == SYSTEM_RUNNING && !oops_in_progress) {
+#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+ if (system_state != SYSTEM_RUNNING)
+ return;
+#endif
+ if ((in_atomic() || irqs_disabled()) && !oops_in_progress) {
if (time_before(jiffies, prev_jiffy + HZ) && prev_jiffy)
return;
prev_jiffy = jiffies;
Index: linux/lib/Kconfig.debug
===================================================================
--- linux.orig/lib/Kconfig.debug
+++ linux/lib/Kconfig.debug
@@ -128,6 +128,17 @@ config DEBUG_SPINLOCK_SLEEP
If you say Y here, various routines which may sleep will become very
noisy if they are called with a spinlock held.

+config DEBUG_SPINLOCK_SLEEP_EARLY_BOOTUP_WORKAROUND
+ bool "Work around sleep-inside-spinlock checking in early bootup code"
+ depends on DEBUG_SPINLOCK_SLEEP
+ help
+ If you say Y here, then early bootup code will not check for
+ "do not call potentially sleeping functions in atomic sections"
+ rule, that the DEBUG_SPINLOCK_SLEEP option enforces.
+
+ You want to say N here, unless your system does not boot with
+ "Y" here.
+
config DEBUG_KOBJECT
bool "kobject debugging"
depends on DEBUG_KERNEL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-01-18 10:21    [W:0.074 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site