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
On Wed, Jan 7, 2009 at 21:47, Ingo Molnar <mingo@elte.hu> wrote:
>
> * 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?

I'm not sure about the qemu case, but at least on my laptop it happens
somewhere along

arch/x86/kernel/cpu/bugs.c:
92 printk(KERN_INFO "Checking 'hlt' instruction... ");
93 if (!boot_cpu_data.hlt_works_ok) {
94 printk("disabled\n");
95 return;
96 }
97 halt();
98 halt();
99 halt();
100 halt();
101 printk("OK.\n");

where an interrupt has to come in order to get the cpu from hlt, so
there is no surprise that I'm seeing this on every single boot. ;)


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