On Thu, Apr 20, 2006 at 06:24:36PM -0700, Michael Chan wrote: > On Fri, 2006-04-21 at 12:40 +1000, Herbert Xu wrote: > > > One simple solution is to establish a separate queue for RTNL-holding > > users or vice versa for non-RTNL holding networking users. That > > would allow the drivers to safely flush the non-RTNL queue while > > holding the RTNL. > > You mean a separate workqueue for net drivers to use instead of the > keventd_wq? Yeah, I think that'll work. Each driver can also create its > own workqueue but that may be a bit more wasteful. >
Isn't the only possibility for a linkwatch deadlock when the __LINK_STATE_LINKWATCH_PENDING but is set in dev->state? Off the top of my head... Would it be interesting to change the calls for flush_scheduled_work() to a new function net_flush_scheduled_work() with the intent on eventually creating new a new work queue but temporarily just checking to make sure there are no linkwatch events pending and if there are allowing them to run first before calling flush_scheduled_work()? This probably isn't a perfect solution, but I thought I'd throw it out there and see what you think.... -andy - 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
