Shirley> This patch has fixed a deadlock problem: the caller calls Shirley> ipoib_put_ah() while holding priv->lock. (In Shirley> ipoib_free_ah() the same lock is reacquired.) This also Shirley> fixes the ipoib_flush_paths() calls __patch_free() Shirley> without holding priv->lock.
You definitely found some bugs but I think the real fix is to make sure that ipoib_put_ah() is called -without- any locks held. That's because for future devices, ib_destroy_ah() may actually sleep (although it won't for mthca). The __path_free in unicast_arp_send() is actually safe to call inside of the lock because we know that we just created the path struct, and therefore it won't have an attached ah, so ipoib_put_ah() can never be called. (Actually it looks like there's a bug in path_rec_create() also -- it doesn't set path->ah to NULL) I think the proper fix for those places calling ipoib_put_ah() inside a lock is to move the ipoib_ah structs to a temporary list and then put them outside of the lock. Thanks, Roland _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general