Herbert Xu <[EMAIL PROTECTED]> writes: > 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.
Regardless of the correctness of where we have ASSERT_RTNL. I think not actually taking the mutex on the assertion failure path (just so we can release it), is still a good deal regardless. For this particular call site clearly we need to look at what is happening a little more. The obvious thing would be to add an explicit might_sleep if we are calling code that can sleep. Eric - 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
