On Mon, 16 Oct 2006, Andrew Morton wrote: > Vaguely. Why doesn't it deadlock if !current_is_keventd()? I mean, > whether or not the caller is keventd, the flush_scheduled_work() caller > will still be dependent upon rtnl_lock() being acquirable.
This !current_is_keventd() condition is just what it is, i.e. a check whether phy_stop_interrupts() has been scheduled through keventd or not. If it has, then flush_scheduled_work() cannot be called; it is not needed anyway. Otherwise phy_stop_interrupts() has to make sure no deferred calls to phy_change() will be made once it has finished. In all cases the assumption is the caller has made sure rtnl_lock() is not held at the time phy_stop_interrupts() is called. That's the very reason for scheduling phy_disconnect() (and hence phy_stop_interrupts()) through keventd. Maciej - 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
