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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
