From 97bff0953dd45a633fa69e1a650d612f5610a60b Mon Sep 17 00:00:00 2001 From: Tobias Diedrich Date: Thu, 3 Jul 2008 23:54:56 -0700 Subject: [PATCH] forcedeth: fix lockdep warning on ethtool -s After enabling CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING I get the following warning when ethtool -s is first called on one of the forcedeth ports: ================================= [ INFO: inconsistent lock state ] 2.6.26-rc4 #28 --------------------------------- inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. ethtool/1985 [HC0[0]:SC0[1]:HE1:SE0] takes: (&np->lock){++..}, at: [] nv_set_settings+0xc8/0x3de [forcedeth] {in-hardirq-W} state was registered at: [] 0xffffffffffffffff irq event stamp: 3606 hardirqs last enabled at (3605): [] _spin_unlock_irqrestore+0x3f/0x68 hardirqs last disabled at (3604): [] _spin_lock_irqsave+0x13/0x46 softirqs last enabled at (3534): [] __do_softirq+0xbc/0xc5 softirqs last disabled at (3606): [] _spin_lock_bh+0x11/0x41 other info that might help us debug this: 2 locks held by ethtool/1985: #0: (rtnl_mutex){--..}, at: [] rtnl_lock+0x12/0x14 #1: (_xmit_ETHER){-+..}, at: [] nv_set_settings+0xb3/0x3de [forcedeth] stack backtrace: Pid: 1985, comm: ethtool Not tainted 2.6.26-rc4 #28 Call Trace: [] print_usage_bug+0x162/0x173 [] mark_lock+0x231/0x41f [] __lock_acquire+0x4e7/0xcac [] ? trace_hardirqs_on+0xf1/0x115 [] ? disable_irq_nosync+0x6f/0x7b [] lock_acquire+0x55/0x6e [] ? :forcedeth:nv_set_settings+0xc8/0x3de [] _spin_lock+0x2f/0x3c [] :forcedeth:nv_set_settings+0xc8/0x3de [] dev_ethtool+0x186/0xea3 [] ? mutex_lock_nested+0x243/0x275 [] ? debug_mutex_free_waiter+0x46/0x4a [] ? mutex_lock_nested+0x266/0x275 [] dev_ioctl+0x4eb/0x600 [] ? _spin_unlock_irqrestore+0x3f/0x68 [] sock_ioctl+0x1f5/0x202 [] vfs_ioctl+0x2a/0x77 [] do_vfs_ioctl+0x25b/0x270 [] ? trace_hardirqs_on_thunk+0x35/0x3a [] sys_ioctl+0x42/0x65 [] system_call_after_swapgs+0x7b/0x80 This is caused by the following snippet in nv_set_settings: netif_carrier_off(dev); if (netif_running(dev)) { nv_disable_irq(dev); netif_tx_lock_bh(dev); spin_lock(&np->lock); /* stop engines */ nv_stop_rxtx(dev); spin_unlock(&np->lock); netif_tx_unlock_bh(dev); } Because of nv_disable_irq this is probably not really a problem though (I guess) and replacing the spin_lock with spin_lock_irqsave could keep interrupts disabled for a longer period of time because of delays in nv_stop_rx and nv_stop_tx. Signed-off-by: Tobias Diedrich Cc: Ayaz Abdulla Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik --- drivers/net/forcedeth.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c index 2cb2447632..20d4fe96a8 100644 --- a/drivers/net/forcedeth.c +++ b/drivers/net/forcedeth.c @@ -4194,12 +4194,23 @@ static int nv_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) netif_carrier_off(dev); if (netif_running(dev)) { + unsigned long flags; + nv_disable_irq(dev); netif_tx_lock_bh(dev); - spin_lock(&np->lock); + /* with plain spinlock lockdep complains */ + spin_lock_irqsave(&np->lock, flags); /* stop engines */ + /* FIXME: + * this can take some time, and interrupts are disabled + * due to spin_lock_irqsave, but let's hope no daemon + * is going to change the settings very often... + * Worst case: + * NV_RXSTOP_DELAY1MAX + NV_TXSTOP_DELAY1MAX + * + some minor delays, which is up to a second approximately + */ nv_stop_rxtx(dev); - spin_unlock(&np->lock); + spin_unlock_irqrestore(&np->lock, flags); netif_tx_unlock_bh(dev); } -- 2.39.5