Hi John, On Mon, 2009-05-18 at 12:22 -0700, John W. Linville wrote: > From: Reinette Chatre <reinette.chatre@xxxxxxxxx> > > Calling cancel_delayed_work() from inside > spin_lock_irqsave, introduces a potential deadlock. > > As explained by Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > > A - lock > T - timer > > phase CPU 1 CPU 2 > --------------------------------------------- > > some place that calls > cancel_timer_sync() > (which is the | code) > lock-irq(A) > | "lock-irq"(T) > | "unlock"(T) > | wait(T) > unlock(A) > > timer softirq > "lock"(T) > run(T) > "unlock"(T) > > irq handler > lock(A) > unlock(A) > > Now all that again, interleaved, leading to deadlock: > > lock-irq(A) > "lock"(T) > run(T) > IRQ during or maybe > before run(T) --> lock(A) > "lock-irq"(T) > wait(T) > > We fix this by moving the call to cancel_delayed_work() into workqueue. > There are cases where the work may not actually be queued or running > at the time we are trying to cancel it, but cancel_delayed_work() is > able to deal with this. > > Also cleanup iwl_set_mode related to this call. This function > (iwl_set_mode) is only called when bringing interface up and there will > thus not be any scanning done. No need to try to cancel scanning. > > Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13224, which was also > reported at http://marc.info/?l=linux-wireless&m=124081921903223&w=2 . > > Tested-by: Miles Lane <miles.lane@xxxxxxxxx> > Signed-off-by: Reinette Chatre <reinette.chatre@xxxxxxxxx> > Acked-by: Zhu Yi <yi.zhu@xxxxxxxxx> > Signed-off-by: John W. Linville <linville@xxxxxxxxxxxxx> > --- > Did not apply to 2.6.30-rc6 as posted -- please verify my fix-up! I am very sorry - this patch was created against and tested with an earlier rc release. Thank you very much for fixing it up. It looks good. Reinette -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
