On Tue, Oct 21, 2014 at 3:50 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2014-10-21 at 15:27 +0300, Eliad Peller wrote: > >> This patch actually solves a kernel panic that can be reproduced >> easily by increasing the delay in ieee80211_scan_completed() and >> removing the driver right after initiating a scan - the delayed >> scan_work never gets flushed, resulting in invalid memory access, etc. > > Yeah I thought about that too - we flush the workqueue but if the timer > hasn't yet fired you can get issues. > > OTOH, the delay there is 0, so the workqueue code doesn't even arm the > timer but rather puts the work on the workqueue immediately. Therefore > flush_work() should be enough? > > Or did you not test with something like > > @@ -357,7 +357,7 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted) > set_bit(SCAN_COMPLETED, &local->scanning); > if (aborted) > set_bit(SCAN_ABORTED, &local->scanning); > - ieee80211_queue_delayed_work(&local->hw, &local->scan_work, 0); > + ieee80211_queue_delayed_work(&local->hw, &local->scan_work, 1); > yeah, that's how i tested it (with a larger delay). you're right about the delay=0. (this might not be enough if scan_work is already delayed_queued, but i currently don't see how this can happen) anyway, the patch looks good. Eliad. -- 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
