Re: [patch 3/6] 2.6.18: sb1250-mac: Phylib IRQ handling fixes

[Andrew Morton <akpm@osdl.org>]

On Fri, 20 Oct 2006 16:40:20 -0500
Andy Fleming <afleming@freescale.com> 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.