Re: 2.6.17-rc5-mm2

[Arjan van de Ven]

On Thu, 2006-06-01 at 17:34 +0159, Jiri Slaby wrote:
> Andrew Morton napsal(a):
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc5/2.6.17-rc5-mm2/
> > 
> Hello,
> 
> just another locking bug, I wonder if this wasn't discussed yet, but I can't
> find it.
> 

this appears to be a genuine bug:

> ============================
> [ BUG: illegal lock usage! ]
> ----------------------------
> illegal {hardirq-on-W} -> {in-hardirq-R} usage.
> events/0/8 [HC1[1]:SC0[0]:HE0:SE1] takes:
>  (hl_irqs_lock){--+.}, at: [<f88e4e09>] highlevel_host_reset+0x15/0x63 [ieee1394]
> {hardirq-on-W} state was registered at:
>   [<c013e3af>] lockdep_acquire+0x59/0x6e
>   [<c03a982c>] _write_lock+0x3e/0x4c
>   [<f88e5772>] hpsb_register_highlevel+0xe1/0x123 [ieee1394]


hpsb_register_highlevel() does
	        write_lock(&hl_irqs_lock);
which is not irq safe
yet

> stack backtrace:
>  [<c03a94a3>] _read_lock+0x3e/0x4c
>  [<f88e4e09>] highlevel_host_reset+0x15/0x63 [ieee1394]

the highlevel_host_reset function

>  [<f88e27f3>] hpsb_selfid_complete+0x222/0x2fe [ieee1394]
>  [<f895fe83>] ohci_irq_handler+0x705/0x9d2 [ohci1394]
>  [<c014b30d>] handle_IRQ_event+0x31/0x65
>  [<c014c52f>] handle_fasteoi_irq+0x6f/0xc8
>  [<c0105b3a>] do_IRQ+0x61/0x87
>  =======================

calls read_lock() from irq context.

this appears to be a genuine and real deadlock 

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