On Mon, Jul 16, 2007 at 08:45:05PM +0300, Ranko Zivojnovic wrote: ... > [NET] gen_estimator deadlock fix > > -Fixes ABBA deadlock noted by Patrick McHardy <[EMAIL PROTECTED]>: > > > There is at least one ABBA deadlock, est_timer() does: > > read_lock(&est_lock) > > spin_lock(e->stats_lock) (which is dev->queue_lock) > > > > and qdisc_destroy calls htb_destroy under dev->queue_lock, which > > calls htb_destroy_class, then gen_kill_estimator and this > > write_locks est_lock. > > To fix the ABBA deadlock the rate estimators are now kept on an rcu list. > > -The est_lock changes the use from protecting the list to protecting > the update to the 'bstat' pointer in order to avoid NULL dereferencing.
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... 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. And if gen_kill_estimator is sometimes run with dev->queue_lock, maybe doing this always would make this locking really understandable and less prone for such inversions (plus est_lock could be forgotten)? Regards, Jarek P. - 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