Re: [PATCH 00/07] dyn_array/nr_irqs/sparse_irq support v10 - fix

[Yinghai Lu]

On Fri, Aug 15, 2008 at 3:28 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> On Fri, 2008-08-15 at 12:19 +0200, Ingo Molnar wrote:
>> * Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
>>
>> > On Fri, 2008-08-15 at 11:35 +0200, Ingo Molnar wrote:
>> >
>> > > looks wrong - it should be unconditional (i've done that via the patch
>> > > below). I dont remember why we made early_init_irq_lock_class()
>> > > dependent on CONFIG_TRACE_IRQFLAGS before. Peter, do you have any
>> > > memories?
>> >
>> > Nope, git suggests I poke you about it.. :-)
>>
>> muhaha - i dont even know that guy who did this sloppy commit 2 years
>> ago - "Ingo Molnar", or however he is called.
>>
>> I believe my (mistaken) thinking would have been that desc->irq lockdep
>> class does not matter as long as we dont do irq-tracing. Which might
>> have been borderline correct then but is wrong now, for things like
>> lockstat?
>
> /me pokes a bit at kconfig dependancies, and yes, it seems you're right
> - lockstat doesn't require irq tracing..

can you check if

#ifdef CONFIG_TRACE_IRQFLAGS
void early_init_irq_lock_class(void)
{
#ifndef CONFIG_HAVE_DYN_ARRAY
        int i;

        for (i = 0; i < nr_irqs; i++)
                lockdep_set_class(&irq_descX[i].lock, &irq_desc_lock_class);
#endif
}
#endif

in kernel/irq/handle.c is right too?

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