On Fri, 20 Oct 2006 16:40:20 -0500 Andy Fleming <afleming@xxxxxxxxxxxxx> wrote: > > The solution is to ignore phy_interrupt() calls if the reported > > device > > has already been halted and calling flush_scheduled_work() from > > phy_stop_interrupts() (but guarded with current_is_keventd() in > > case > > the function has been called through keventd from the MAC device's > > close call to avoid a deadlock on the netlink lock). > > > I've been trying to figure out this problem since you posted this, > and I'm not sure I understand it fully Me either, but I basically gave up. If it is deadlocky for keventd to call flush_scheduled_work() I fail to see why it is not deadlocky for other processes. If the caller of flush_scheduled_work() holds rtnl_lock, and if a queued work callback also takes rtnl_lock then the flush_scheduled_work() caller will deadlock regardless of whether or not it is keventd. Because the flush_scheduled_work() caller holds a lock which will prevent the flush from completing.
