bonding: Fix deadlock in bonding driver resulting from internal locking when using...
authorNeil Horman <nhorman@tuxdriver.com>
Wed, 13 Oct 2010 16:01:50 +0000 (16:01 +0000)
committerDavid S. Miller <davem@davemloft.net>
Mon, 18 Oct 2010 15:32:07 +0000 (08:32 -0700)
commite843fa50887582c867d8b7995f81fe9c1a076806
tree5a8e34f5afaeeed539d519b0e91b7a4c92268b11
parentc2355e1ab910278a94d487b78590ee3c8eecd08a
bonding: Fix deadlock in bonding driver resulting from internal locking when using netpoll

The monitoring paths in the bonding driver take write locks that are shared by
the tx path.  If netconsole is in use, these paths can call printk which puts us
in the netpoll tx path, which, if netconsole is attached to the bonding driver,
result in deadlock (the xmit_lock guards are useless in netpoll_send_skb, as the
monitor paths in the bonding driver don't claim the xmit_lock, nor should they).
The solution is to use a per cpu flag internal to the driver to indicate when a
cpu is holding the lock in a path that might recusrse into the tx path for the
driver via netconsole.  By checking this flag on transmit, we can defer the
sending of the netconsole frames until a later time using the retransmit feature
of netpoll_send_skb that is triggered on the return code NETDEV_TX_BUSY.  I've
tested this and am able to transmit via netconsole while causing failover
conditions on the bond slave links.

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/bonding/bond_main.c
drivers/net/bonding/bond_sysfs.c
drivers/net/bonding/bonding.h