Re: linux-next: Tree for December 11

[Ingo Molnar <mingo@elte.hu>]

* Alexey Zaytsev <alexey.zaytsev@gmail.com> wrote:

> And last time I bisected, it pointed to:
> 
> commit 7317d7b87edb41a9135e30be1ec3f7ef817c53dd
> Author: Nick Piggin <nickpiggin@yahoo.com.au>
> Date:   Tue Sep 30 20:50:27 2008 +1000
> 
>    sched: improve preempt debugging
>
> 
>    This patch helped me out with a problem I recently had....
> 
>    Basically, when the kernel lock is held, then preempt_count
> underflow does not
>    get detected until it is released which may be a long time (and arbitrarily,
>    eg at different points it may be rescheduled). If the bkl is released at
>    schedule, the resulting output is actually fairly cryptic...
> 
>    With any other lock that elevates preempt_count, it is illegal to schedule
>    under it (which would get found pretty quickly). bkl allows scheduling with
>    preempt_count elevated, which makes underflows hard to debug.
> 
>    Signed-off-by: Ingo Molnar <mingo@elte.hu>
> 
> so at least a dumb bisection won't do here.

ah, sorry for being a slow starter, i missed that bit - merge window 
attention span troubles ...

I think the kernel_locked() check added here is plain buggy against IRQ 
contexts: we drop the BKL spinlock and reduce current->kernel_depth 
non-atomically.

So kernel_locked() can become detached from the preempt_count().

Nick, can you think of any better way of still saving this debug check, or 
should we revert it?

Although it seems a bit weird how consistently you seem to be able to 
trigger it - as this seems to be a narrow race. Is there an IRQ storm 
there perhaps, or something widens things up for Qemu to inject an IRQ 
right there?

	Ingo