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

Reply via email to