Messages in this thread Patch in this message | | | Date | Wed, 18 Jan 2006 10:18:34 +0100 | From | Ingo Molnar <> | 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/
| |