On Sat, Dec 15, 2007 at 02:48:10AM -0800, Andrew Morton wrote: > > When Eric said > > > Way way deep in mutex debugging on the slowpath there is a unreadable > > and incomprehensible WARN_ON in muxtex_trylock that will trigger if > > you have 10 tons of debugging turned on, and you are in, > > interrupt context, and you manage to hit the slow path. I think that > > is a pretty unlikely scenario. > > I think he's still right. That's if the warning which he managed to find > even still exists.
Well at the very start he said: : 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. This is what threw me off as it implied that we were warning about ASSERT_RTNL calls in any atomic context, including those with just soft IRQs disabled, which is an important distinction for the networking subsystem. Had he said that it was just IRQ handlers rather than soft IRQs then we wouldn't be having this discussion now :) > I think the change which Eric proposed is a good one: it converts > ASSERT_RTNL() from an atomic rmw which dirties a cacheline which will > sometimes be owned by a different CPU into a plain old read. It's going to > make ASSERT_RTNL() heaps cheaper. I agree. Although paths using ASSERT_RTNL shouldn't be performance critical since the RTNL should only be held for control operations as opposed to data transport. > Now as a separate issue we (ie: you) need to work out what _other_ things > you want ASSERT_RTNL to check apart from "rtnl must be held". Since we have now established that ASSERT_RTNL never actually warned about usage on paths with BH off, I think Eric's original patch is fine as it is and I owe him an apology. 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
