mac80211 breakage on broadcom hardware.

mac80211 appears to be broken by commit 921dda3b092b3d47c9b715d02be0c2615c8d7aa8 .

An oops occurs on 4306 and 4318 broadcom hardware the minute the device attempt to scan for any AP's in the area. I have attached the oops for review.

-Jory

Pid: 1561, comm: b43 Not tainted 2.6.24-rc8 #1

RIP: 0010:[<ffffffff805dc53e>]  [<ffffffff805dc53e>] ieee80211_sta_scan_work+0x12e/0x200
RSP: 0018:ffff81004597fe70  EFLAGS: 00010282
RAX: 0000000000000000 RBX: dead4ead00000001 RCX: 0000000000000002
RDX: ffff8100459c20c0 RSI: ffff8100458c96e0 RDI: ffff8100459c3028
RBP: ffff8100459c2380 R08: ffff810046816988 R09: 00000000000003c3
R10: 0000000000000000 R11: ffffffff80588120 R12: ffff8100459c3028
R13: ffff8100458c9000 R14: ffff810046816978 R15: 0000000000000000
FS:  00002b292429f130(0000) GS:ffffffff807ae000(0000) knlGS:00000000f7e346c0
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000000007b5d70 CR3: 00000000438c7000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process b43 (pid: 1561, threadinfo ffff81004597e000, task ffff8100459bcf80)
Stack:  0000000000000282 ffff8100459c3030 ffff810046816960 ffff8100459c3028
 ffffffff805dc410 ffffffff80241fb7 ffff810046816988 ffff810046816960
 ffffffff80242920 ffff810046816978 0000000000000000 ffffffff802429c3
Call Trace:
 [<ffffffff805dc410>] ieee80211_sta_scan_work+0x0/0x200
 [<ffffffff80241fb7>] run_workqueue+0x87/0x120
 [<ffffffff80242920>] worker_thread+0x0/0x110
 [<ffffffff802429c3>] worker_thread+0xa3/0x110
 [<ffffffff802461b0>] autoremove_wake_function+0x0/0x30
 [<ffffffff80242920>] worker_thread+0x0/0x110
 [<ffffffff80242920>] worker_thread+0x0/0x110
 [<ffffffff80245deb>] kthread+0x4b/0x80
 [<ffffffff8020c3f8>] child_rip+0xa/0x12
 [<ffffffff80245da0>] kthread+0x0/0x80
 [<ffffffff8020c3ee>] child_rip+0x0/0x12


Code: 3b 43 14 7c 0d 83 bd 98 0c 00 00 01 0f 87 6d ff ff ff 4c 63 
RIP  [<ffffffff805dc53e>] ieee80211_sta_scan_work+0x12e/0x200
 RSP <ffff81004597fe70>
---[ end trace 6fe81bf2464e88d1 ]---

Hm, I'm not sure this hunk is correct.

@@ -3194,44 +3223,47 @@ void ieee80211_sta_scan_work(struct work_struct *work)

switch (local->scan_state) {
case SCAN_SET_CHANNEL:
- mode = local->scan_hw_mode;
- if (local->scan_hw_mode->list.next == &local->modes_list &&
- local->scan_channel_idx >= mode->num_channels) {
+ /* get current scan band */
+ if (local->scan_band < IEEE80211_NUM_BANDS)
+ sband = local->hw.wiphy->bands[local->scan_band];
+ else
+ sband = NULL;
+
+ /* if we started at an unsupported one, advance */
+ while (!sband && local->scan_band < IEEE80211_NUM_BANDS) {
+ local->scan_band++;
+ sband = local->hw.wiphy->bands[local->scan_band];
+ local->scan_channel_idx = 0;
+ }

What are we doing here?
b43 does only define one band (2.4GHz) currently. Is it possible that this code selects the uninitialized 5GHz band structure?

+
+ if (!sband ||
+ (local->scan_channel_idx >= sband->n_channels &&
+ local->scan_band >= IEEE80211_NUM_BANDS)) {
ieee80211_scan_completed(local_to_hw(local)); return;
}
- skip = !(local->enabled_modes & (1 << mode->mode));
- chan = &mode->channels[local->scan_channel_idx];
- if (!(chan->flag & IEEE80211_CHAN_W_SCAN) ||
+ skip = 0;
+ chan = &sband->channels[local->scan_channel_idx];

If the above can happen, this would crash when using "chan".

I thought about this a long time and I'm pretty sure that it cannot select a NULL band structure as long as there is at least one band structure which is guaranteed by cfg80211 core code.

scan_band always starts out at IEEE80211_BAND_2GHZ, and once it reaches NUM_BANDS the scan is aborted, and it can't select NULL bands because one band is guaranteed to be non-NULL (and after this loop we abort if sband == NULL)

johannes