Jay Vosburgh <[EMAIL PROTECTED]> wrote: > > Can you test the following and let me know if it triggers the > warning? I believe this is the minimum locking needed, and based on > input from Herbert, we shouldn't need to hold the lock at _bh. If this > one works, and nobody sees any other issues with it, then it's the final > patch for this lockdep problem. I'll add some deep, meaningful comments > to explain the locking a bit (i.e., we're called with rtnl for the > allmulti and promisc cases, so we're ok there without additional locks, > but the later code could be called from anywhere, so it needs locks to > prevent the slave list from changing, but the mc_lists themselves are > covered by the netif_tx_lock that all callers will hold), but this would > be the actual code change.
I just had a look at the bonding code and while I didn't find anything wrong with the change of the write lock to a read lock, the mc_list itself does not seem to have adequete protection. In particular, there doesn't seem to be anything protecting the walking of mc_list in bond_enslave. This could be a problem if we have an IGMP6 event triggering the change in the master's mc_list. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
