Jarek Poplawski wrote: > This patch looks fine, but while checking for this lock I've found > another strange thing: for actions tcfc_stats_lock is used here, which > is equivalent to tcfc_lock; so, in gen_kill_estimator we get this lock > sometimes after dev->queue_lock; this order is also possible during > tc_classify if actions are used; on the other hand act_mirred calls > dev_queue_xmit under this lock, so dev->queue_lock is taken in another > order. I hope it's with different devs, and there is no real deadlock > possible, but this all is a bit queer...
It *should* be a different device, but AFAIK nothing enforces this. There are quite a few possible deadlocks with TC actions, mid-term things like the mirred action need to be redesigned to inject packet from a different context. > I don't know actions enough, but it seems, if it's possible that they > are always run only from tc_classify, with dev->queue_lock, maybe it > would be simpler to use this lock for actions' stats with > gen_estimator too. The same action can be shared between devices, so they need seperate locks. - 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
