How about putting the mtu stuff in another task, that is scheduled on another workqueue, such as the global workqueue? We can use the data field of the work to syncronize with device cleanup.
On Thu, Aug 7, 2008 at 6:26 PM, Roland Dreier <[EMAIL PROTECTED]> wrote: > > > Instead of loop-waiting for the lock, give it up if can't lock. > > Same thing is done in drivers/net/cxgb3/cxgb3_main.c. > > I think this is worse ... now if there's anything (*anything* at all -- > even stuff related to different devices) holding the rtnl lock at the > wrong time, we lose an mtu update. > > I haven't had a chance to look at this in detail yet, but I would really > like to investigate whether we can just avoid the potential deadlock in > some more elegant way. > _______________________________________________ > general mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
