ng:bond_release+0x1b4/0x450 [] __down_write_nested+0x12/0x92 [] :bonding:bonding_store_slaves+0x25c/0x2f7 [] sysfs_write_file+0xb9/0xe8 [] vfs_write+0xce/0x174 [] sys_write+0x45/0x6e [] tracesys+0xd5/0xe0 It occurs because we are able to change the slave configuarion of a bond while the bond interface is down. The bonding driver initializes some data structures only after its ndo_open routine is called. Among them is the initalization of the alb tx and rx hash locks. So if we add or remove a slave without first opening the bond master device, we run the risk of trying to lock/unlock a spinlock that has garbage for data in it, which results in our above softlock. Note that sometimes this works, because in many cases an unlocked spinlock has the raw_lock parameter initialized to zero (meaning that the kzalloc of the net_device private data is equivalent to calling spin_lock_init), but thats not true in all cases, and we aren't guaranteed that condition, so we need to pass the relevant spinlocks through the spin_lock_init function. Fix it by moving the spin_lock_init calls for the tx and rx hashtable locks to the ndo_init path, so they are ready for use by the bond_store_slaves path. Change notes: v2) Based on conversation with Jay and Nicolas it seems that the ability to enslave devices while the bond master is down should be safe to do. As such this is an outlier bug, and so instead we'll just initalize the errant spinlocks in the init path rather than the open path, solving the problem. We'll also remove the warnings about the bond being down during enslave operations, since it should be safe v3) Fix spelling error Signed-off-by: Neil Horman Reported-by: jtluka@redhat.com CC: Jay Vosburgh CC: Andy Gospodarek CC: nicolas.2p.debian@gmail.com CC: "David S. Miller" Signed-off-by: Jay Vosburgh Signed-off-by: David S. Miller