On Fri, 20 Oct 2006 16:40:20 -0500
Andy Fleming <[EMAIL PROTECTED]> 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.

-
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

Reply via email to