lkml.org 
[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: Tree for December 11

* 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


\
 
 \ /
  Last update: 2009-01-07 19:49    [W:0.035 / U:2.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site