Re: 2.6.23-rc2-mm2 -- When suspending, "INFO: inconsistent lock state" -- 8139too issue?

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 10 Aug 2007 14:32:27 -0400
"Miles Lane" <miles.lane@gmail.com> wrote:

> [ INFO: inconsistent lock state ]
> 2.6.23-rc2-mm2 #10
> ---------------------------------
> inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
> ifconfig/8425 [HC0[0]:SC0[0]:HE1:SE1] takes:
>  (&tp->lock){++..}, at: [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
> {in-hardirq-W} state was registered at:
>   [<c0133ede>] __lock_acquire+0x3f0/0xb6f
>   [<c01346be>] lock_acquire+0x61/0x7d
>   [<c03127b4>] _spin_lock+0x23/0x32
>   [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
>   [<c0143f96>] handle_IRQ_event+0x1a/0x46
>   [<c0144f2f>] handle_fasteoi_irq+0x72/0xab
>   [<c0105b82>] do_IRQ+0xab/0xd5
>   [<ffffffff>] 0xffffffff
> irq event stamp: 1551
> hardirqs last  enabled at (1551): [<c0161db2>] kfree+0xb9/0xc3
> hardirqs last disabled at (1550): [<c0161d5c>] kfree+0x63/0xc3
> softirqs last  enabled at (1530): [<c02a6510>] dev_deactivate+0x86/0x9f
> softirqs last disabled at (1528): [<c03127ce>] _spin_lock_bh+0xb/0x37
> 
> other info that might help us debug this:
> 1 lock held by ifconfig/8425:
>  #0:  (rtnl_mutex){--..}, at: [<c03116b7>] mutex_lock+0x1c/0x1f
> 
> stack backtrace:
>  [<c0104c92>] show_trace_log_lvl+0x12/0x25
>  [<c0105476>] show_trace+0xd/0x10
>  [<c010557a>] dump_stack+0x15/0x17
>  [<c0132af2>] print_usage_bug+0x10a/0x117
>  [<c01332fc>] mark_lock+0x1e0/0x3fa
>  [<c0133f59>] __lock_acquire+0x46b/0xb6f
>  [<c01346be>] lock_acquire+0x61/0x7d
>  [<c03127b4>] _spin_lock+0x23/0x32
>  [<f882f65a>] rtl8139_interrupt+0x22/0x37e [8139too]
>  [<c0144453>] free_irq+0xc0/0xe9
>  [<f88308f0>] rtl8139_close+0xa0/0x130 [8139too]
>  [<c0299767>] dev_close+0x4d/0x6a
>  [<c0298a70>] dev_change_flags+0x9f/0x152
>  [<c02d057d>] devinet_ioctl+0x209/0x505
>  [<c02d0e9a>] inet_ioctl+0x86/0xa4
>  [<c028fa47>] sock_ioctl+0x1a6/0x1c4
>  [<c016e532>] do_ioctl+0x22/0x67
>  [<c016e7c9>] vfs_ioctl+0x252/0x265
>  [<c016e808>] sys_ioctl+0x2c/0x48
>  [<c0103cea>] sysenter_past_esp+0x5f/0x99
>  =======================
> ACPI: PCI interrupt for device 0000:01:00.0 disabled
> ACPI: PCI interrupt for device 0000:01:06.0 disabled
> ieee80211_crypt: unregistered algorithm 'NULL'
> Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> 

OK, what's happened here is that lockdep has decided that 8139too's
tp->lock is a taken-from-interrupts lock.  Then it sees that lock being
taken from regular old process context and it says "hey, if an interrupt
were to happen now, you'd deadlock".

The offending callsite is free_irq():

#ifdef CONFIG_DEBUG_SHIRQ
	if (handler) {
		/*
		 * It's a shared IRQ -- the driver ought to be prepared for it
		 * to happen even now it's being freed, so let's make sure....
		 * We do this after actually deregistering it, to make sure that
		 * a 'real' IRQ doesn't run in parallel with our fake
		 */
		handler(irq, dev_id);
	}
#endif

Ingo: recommendations, please?  Put a local_irq_save() around it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/