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

* Alexey Zaytsev <> wrote:

> And last time I bisected, it pointed to:
> commit 7317d7b87edb41a9135e30be1ec3f7ef817c53dd
> Author: Nick Piggin <>
> 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 <>
> 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

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?


 \ /
  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