Re: [PATCH] mac80211: fix scan channel race

["Luis R. Rodriguez" <mcgrof@gmail.com>]

On Thu, May 7, 2009 at 5:23 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> When a software scan starts, it first sets sw_scanning, but
> leaves the scan_channel "unset" (it currently actually gets
> initialised to a default). Now, when something else tries
> to (re)configure the hardware in the window between these two
> events (after sw_scanning = true, but before scan_channel is
> set), the current code switches to the (unset!) scan_channel.
> This causes trouble, especially when switching bands and
> sending frames on the wrong channel.
>
> To work around this, leave scan_channel initialised to NULL
> and use it to determine whether or not a switch to a different
> channel should occur (and also use the same condition to check
> whether to adjust power for scan or not).
>
> Additionally, avoid reconfiguring the hardware completely when
> recalculating idle resulted in no changes, this was the problem
> that originally led us to discover the race condition in the
> first place, which was helpfully bisected by Pavel. This part
> of the patch should not be necessary with the other fixes, but
> not calling the ieee80211_hw_config function when we know it to
> be unnecessary is certainly a correct thing to do.
>
> Unfortunately, this patch cannot and does not fix the race
> condition completely, but due to the way the scan code is
> structured it makes the particular problem Pavel discovered
> (race while changing channel at the same time as transmitting
> frames) go away. To fix it completely, more work especially
> with locking configuration is needed.
>
> Bisected-by: Pavel Roskin <proski@gnu.org>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

I've tested this on a dual band card and in fact as I expected it
cured the oops we were seeing with ath9k.

  Luis