Hi, As reported last week by Or Gerlitz and confirmed by me, there is a kernel crash when trying to unenslave all ib slaves (which leads to bonding master destruction). I also found that it happens with Ethernet slaves if following the steps:
1. unenslaving all slaves via sysfs 2. deleting the bonding master via sysfs I see that in commit 6603a6f25e4bca922a7dfbf0bf03072d98850176 the order of the bonding master destruction sequence was changed in 2 places (a part of the commitdiff is below). Although I might be missing something it looks like a bug to me to dereference the dev pointer after unregistering it. Am I right? I also see that the kernel crash doesn't happen when reverting from this (part of) the patch. I'd like to have your opinion please. thanks MoniS --------------------------------------------------------- commit 6603a6f25e4bca922a7dfbf0bf03072d98850176 Author: Jay Vosburgh <[EMAIL PROTECTED]> Date: Wed Oct 17 17:37:50 2007 -0700 bonding: Convert more locks to _bh, acquire rtnl, for new locking Convert more lock acquisitions to _bh flavor to avoid deadlock with workqueue activity and add acquisition of RTNL in appropriate places. Affects ALB mode, as well as core bonding functions and sysfs. Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -1846,9 +1846,9 @@ int bond_release(struct net_device *bond */ void bond_destroy(struct bonding *bond) { + unregister_netdevice(bond->dev); bond_deinit(bond->dev); bond_destroy_sysfs_entry(bond); - unregister_netdevice(bond->dev); } . . . @@ -4473,8 +4473,8 @@ static void bond_free_all(void) bond_mc_list_destroy(bond); /* Release the bonded slaves */ bond_release_all(bond_dev); - bond_deinit(bond_dev); unregister_netdevice(bond_dev); + bond_deinit(bond_dev); } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html