Re: [patch] turn on might_sleep() in early bootup code too

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> >  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.
> 
> I get just the one on ppc64:
> 
> 
> Debug: sleeping function called from invalid context at include/asm/semaphore.h:62
> in_atomic():1, irqs_disabled():1
> Call Trace:
> [C0000000004EFD20] [C00000000000F660] .show_stack+0x5c/0x1cc (unreliable)
> [C0000000004EFDD0] [C000000000053214] .__might_sleep+0xbc/0xe0
> [C0000000004EFE60] [C000000000413D1C] .lock_kernel+0x50/0xb0
> [C0000000004EFEF0] [C0000000004AC574] .start_kernel+0x1c/0x278
> [C0000000004EFF90] [C0000000000085D4] .hmt_init+0x0/0x2c
> 
> 
> Your fault ;)

yes :-) I have a really ugly workaround in my tree that is definitely 
not worth posting. I think to do this cleanly i'll add trylock_kernel(), 
and do this in main.c:

   BUG_ON(!trylock_kernel());

but there's another one that is much nastier in terms of scope:

BUG: sleeping function called from invalid context at kernel/mutex.c:256
in_atomic():0, irqs_disabled():1
 [<c0103db6>] show_trace+0xd/0xf
 [<c0103dcd>] dump_stack+0x15/0x17
 [<c011ff4b>] __might_sleep+0x64/0x6c
 [<c105b470>] mutex_lock_interruptible+0x15/0x22
 [<c013d81f>] __lock_cpu_hotplug+0x26/0x52
 [<c013d858>] lock_cpu_hotplug_interruptible+0xd/0xf
 [<c013d922>] register_cpu_notifier+0xc/0x2b
 [<c1dac88f>] page_alloc_init+0xd/0xf
 [<c1d992ee>] start_kernel+0x125/0x376
 [<c0100210>] 0xc0100210

this is what is causing the ppc64 problems too i think.

lock_cpu_hotplug() has design problems i think: hotplug-locked sections 
are slowly spreading in the kernel, encompassing more and more code :-) 
Shouldnt the CPU hotplug lock be a spinlock to begin with?

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/