Eric W. Biederman <[EMAIL PROTECTED]> wrote: > > Currently we have the call path: > macvlan_open -> dev_unicast_add -> __dev_set_rx_mode -> > __dev_set_promiscuity -> ASSERT_RTNL -> mutex_trylock > > When mutex debugging is on taking a mutex complains if we are not > allowed to sleep. At that point we have called netif_tx_lock_bh > so we are clearly not allowed to sleep. Arguably this is not a > problem for mutex_trylock.
Actually holding the TX lock here is a bug. We're going to call down into the hardware with __dev_set_promiscuity, which may sleep (think USB NICs), so we definitely shouldn't be holding any spin locks. Patrick, could we avoid taking the TX lock here somehow? 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
