linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* NULL pointer in mac80211:ieee80211_associate
@ 2008-05-16 21:28 Larry Finger
  2008-05-16 21:47 ` Johannes Berg
  0 siblings, 1 reply; 6+ messages in thread
From: Larry Finger @ 2008-05-16 21:28 UTC (permalink / raw)
  To: wireless, Johannes Berg

I think this report is new. If it is a duplicate, I apologize for any noise. 
My kernel is from wireless-testing. A 'uname -r' commands yields 
2.6.26-rc2-wl-07884-g5d3790d-dirty. It is "dirty" due to some trial patches 
in the b43 driver that should not have any effect on this oops. The computer 
is running the x86_64 version of openSUSE 10.3, and I have not seen this oops 
before.

The system was last booted at 18:02 on May 15. Until 10:10:58, everything 
seemed normal. Then a reason 3 deauthentication arrived, and the following 
ensued:

May 16 10:10:58 larrylap kernel: eth1: deauthenticate(reason=3)
May 16 10:10:58 larrylap kernel: eth1: RX deauthentication from 
00:1a:70:46:ba:b1 (reason=15)
May 16 10:10:58 larrylap kernel: eth1: deauthenticated
May 16 10:10:58 larrylap avahi-daemon[3042]: Withdrawing address record for 
192.168.1.122 on eth1.
May 16 10:10:58 larrylap avahi-daemon[3042]: Leaving mDNS multicast
  group on interface eth1.IPv4 with address 192.168.1.122.
May 16 10:10:58 larrylap avahi-daemon[3042]: Interface eth1.IPv4 no longer 
relevant for mDNS.
May 16 10:10:59 larrylap kernel: eth1: authenticate with AP 00:1a:70:46:ba:b1
May 16 10:10:59 larrylap kernel: eth1: RX authentication from 
00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
May 16 10:10:59 larrylap kernel: eth1: authenticated
May 16 10:10:59 larrylap kernel: eth1: associate with AP 00:1a:70:46:ba:b1
May 16 10:10:59 larrylap kernel: BUG: unable to handle kernel NULL pointer 
dereference at 00000000000000c0
May 16 10:10:59 larrylap kernel: IP: [<ffffffffa0159eb1>] 
:mac80211:ieee80211_associate+0x2ba/0x53e
May 16 10:10:59 larrylap kernel: PGD b8258067 PUD b8259067 PMD 0
May 16 10:10:59 larrylap kernel: Oops: 0000 [1] SMP
May 16 10:10:59 larrylap kernel: CPU 0
May 16 10:10:59 larrylap kernel: Modules linked in: af_packet snd_pcm_oss 
snd_mixer_oss snd_seq snd_seq_device sunrpc rfki
ll_input cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 
fuse loop dm_mod snd_hda_intel snd_pcm sr_mo
d snd_timer snd soundcore k8temp hwmon cdrom snd_page_alloc forcedeth 
serio_raw ac battery sg arc4 ecb crypto_blkcipher bu
tton b43 firmware_class ssb rfkill mac80211 joydev cfg80211 led_class 
input_polldev ohci_hcd ehci_hcd sd_mod usbcore edd e
xt3 mbcache jbd fan ahci pata_amd libata scsi_mod dock thermal processor
May 16 10:10:59 larrylap kernel: Pid: 1684, comm: b43 Not tainted 
2.6.26-rc2-wl-07884-g5d3790d-dirty #3
May 16 10:10:59 larrylap kernel: RIP: 0010:[<ffffffffa0159eb1>] 
[<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/
0x53e
May 16 10:10:59 larrylap kernel: RSP: 0018:ffff8100b9fdbb50  EFLAGS: 00010246
May 16 10:10:59 larrylap kernel: RAX: 0000000000000000 RBX: ffff8100b96ef410 
RCX: 0000000000000000
May 16 10:10:59 larrylap kernel: RDX: ffff810037b88000 RSI: 0000000000000000 
RDI: ffff8100b96ef42e
May 16 10:10:59 larrylap kernel: RBP: 0000000000000000 R08: 0000000000000000 
R09: ffff8100b8ee7780
May 16 10:10:59 larrylap kernel: R10: ffff8100b8a3e480 R11: ffff8100b8a3e480 
R12: ffff810037b88b90
May 16 10:10:59 larrylap kernel: R13: ffff8100b8ee7780 R14: ffff8100b96ef42c 
R15: ffffffffa01bbb70
May 16 10:10:59 larrylap kernel: FS:  00007fab6fcac700(0000) 
GS:ffffffff8054e000(0000) knlGS:00000000f6398b10
May 16 10:10:59 larrylap kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 
000000008005003b
May 16 10:10:59 larrylap kernel: CR2: 00000000000000c0 CR3: 00000000b8257000 
CR4: 00000000000006e0
May 16 10:10:59 larrylap kernel: DR0: 0000000000000000 DR1: 0000000000000000 
DR2: 0000000000000000
May 16 10:10:59 larrylap kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 
DR7: 0000000000000400
May 16 10:10:59 larrylap kernel: Process b43 (pid: 1684, threadinfo 
ffff8100b9fda000, task ffff8100b871e780)
May 16 10:10:59 larrylap kernel: Stack:  ffffffff8028c3d0 ffff810037b88000 
ffffffff8028bdc1 0000000037b88be0
May 16 10:10:59 larrylap kernel:  ffff810037b88c24 0000000000000000 
30373a61313a3030 623a61623a36343a
May 16 10:10:59 larrylap kernel:  ffff8100bb6b0031 ffff8100b9fdbd20 
ffff8100b878a034 0000000000000002
May 16 10:10:59 larrylap kernel: Call Trace:
May 16 10:10:59 larrylap kernel:  [<ffffffff8028c3d0>] kfree+0x1d6/0x1e5
May 16 10:10:59 larrylap kernel:  [<ffffffff8028bdc1>] 
kmem_cache_free+0x19b/0x1aa
May 16 10:10:59 larrylap kernel:  [<ffffffffa015a816>] 
:mac80211:ieee80211_sta_rx_queued_mgmt+0x54b/0xf0b
May 16 10:10:59 larrylap kernel:  [<ffffffffa0162376>] 
:mac80211:ieee80211_master_start_xmit+0x3af/0x3cc
May 16 10:10:59 larrylap kernel:  [<ffffffff802377ef>] 
local_bh_enable_ip+0xd0/0xd7
May 16 10:10:59 larrylap kernel:  [<ffffffff8024e48c>] mark_held_locks+0x58/0x72
May 16 10:10:59 larrylap kernel:  [<ffffffff803f8fb7>] 
_spin_unlock_irqrestore+0x3f/0x46
May 16 10:10:59 larrylap kernel:  [<ffffffff8024e61c>] 
trace_hardirqs_on+0xef/0x113
May 16 10:10:59 larrylap kernel:  [<ffffffffa015b912>] 
:mac80211:ieee80211_sta_work+0xb6/0x738
May 16 10:10:59 larrylap kernel:  [<ffffffff803f8e94>] _spin_unlock_irq+0x24/0x27
May 16 10:10:59 larrylap kernel:  [<ffffffff8024e61c>] 
trace_hardirqs_on+0xef/0x113
May 16 10:10:59 larrylap kernel:  [<ffffffffa015b85c>] 
:mac80211:ieee80211_sta_work+0x0/0x738
May 16 10:10:59 larrylap kernel:  [<ffffffff8024162b>] run_workqueue+0xe3/0x1ec
May 16 10:10:59 larrylap kernel:  [<ffffffff80242115>] worker_thread+0xdc/0xeb
May 16 10:10:59 larrylap kernel:  [<ffffffff80244b67>] 
autoremove_wake_function+0x0/0x2e
May 16 10:10:59 larrylap kernel:  [<ffffffff80242039>] worker_thread+0x0/0xeb
May 16 10:10:59 larrylap kernel:  [<ffffffff80244a4b>] kthread+0x47/0x74
May 16 10:10:59 larrylap kernel:  [<ffffffff803f8921>] 
trace_hardirqs_on_thunk+0x35/0x3a
May 16 10:10:59 larrylap kernel:  [<ffffffff8020ccf8>] child_rip+0xa/0x12
May 16 10:10:59 larrylap kernel:  [<ffffffff8020c40f>] restore_args+0x0/0x30
May 16 10:10:59 larrylap kernel:  [<ffffffff802448c2>] kthreadd+0x17f/0x1a4
May 16 10:10:59 larrylap kernel:  [<ffffffff80244a04>] kthread+0x0/0x74
May 16 10:10:59 larrylap kernel:  [<ffffffff8020ccee>] child_rip+0x0/0x12
May 16 10:10:59 larrylap kernel:
May 16 10:10:59 larrylap kernel:
May 16 10:10:59 larrylap kernel: Code: 00 49 89 c6 49 8b 84 24 b8 00 00 00 49 
8d 7e 02 fc 41 88 46 01 49 8b 8c 24 b8 00 00 00 48 8b 74 24 20 f3 a4 31 f6 48 
8b 4c 24 28 <4c> 8b 89 c0 00 00 00 48 c7 44 24 10 00 00 00 00 eb 4a 48 8b 5c
May 16 10:10:59 larrylap kernel: RIP  [<ffffffffa0159eb1>] 
:mac80211:ieee80211_associate+0x2ba/0x53e
May 16 10:10:59 larrylap kernel: RIP  [<ffffffffa0159eb1>] 
:mac80211:ieee80211_associate+0x2ba/0x53e
May 16 10:10:59 larrylap kernel:  RSP <ffff8100b9fdbb50>
May 16 10:10:59 larrylap kernel: CR2: 00000000000000c0
May 16 10:10:59 larrylap kernel: ---[ end trace 0010c8900b24b09d ]---

Please let me know if you need additional information.

Larry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: NULL pointer in mac80211:ieee80211_associate
  2008-05-16 21:28 NULL pointer in mac80211:ieee80211_associate Larry Finger
@ 2008-05-16 21:47 ` Johannes Berg
  2008-05-16 23:05   ` Larry Finger
  0 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2008-05-16 21:47 UTC (permalink / raw)
  To: Larry Finger; +Cc: wireless

[-- Attachment #1: Type: text/plain, Size: 6692 bytes --]

Larry,

> I think this report is new. If it is a duplicate, I apologize for any noise. 

I've definitely not seen it before, thanks.

> The system was last booted at 18:02 on May 15. Until 10:10:58, everything 
> seemed normal. Then a reason 3 deauthentication arrived, and the following 
> ensued:

Actually, the deauthentication is what you're sending, see
ieee80211_sta_deauthenticate (in mlme.c). Any idea why it would be sent?
Did you kill wpa_supplicant or something similar?

In any case, we wouldn't expect to get a deauth with reason 15
(WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT) then. Hmm. Maybe that's why
wpa_supplicant was trying to disassociate as well?

Still, we should of course not crash :)

> May 16 10:10:58 larrylap kernel: eth1: deauthenticate(reason=3)
> May 16 10:10:58 larrylap kernel: eth1: RX deauthentication from 00:1a:70:46:ba:b1 (reason=15)
> May 16 10:10:58 larrylap kernel: eth1: deauthenticated
> May 16 10:10:58 larrylap avahi-daemon[3042]: Withdrawing address record for 
> 192.168.1.122 on eth1.
> May 16 10:10:58 larrylap avahi-daemon[3042]: Leaving mDNS multicast
>   group on interface eth1.IPv4 with address 192.168.1.122.
> May 16 10:10:58 larrylap avahi-daemon[3042]: Interface eth1.IPv4 no longer 
> relevant for mDNS.
> May 16 10:10:59 larrylap kernel: eth1: authenticate with AP 00:1a:70:46:ba:b1
> May 16 10:10:59 larrylap kernel: eth1: RX authentication from 
> 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
> May 16 10:10:59 larrylap kernel: eth1: authenticated
> May 16 10:10:59 larrylap kernel: eth1: associate with AP 00:1a:70:46:ba:b1
> May 16 10:10:59 larrylap kernel: BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
> May 16 10:10:59 larrylap kernel: IP: [<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/0x53e
> May 16 10:10:59 larrylap kernel: PGD b8258067 PUD b8259067 PMD 0
> May 16 10:10:59 larrylap kernel: Oops: 0000 [1] SMP
> May 16 10:10:59 larrylap kernel: CPU 0
> May 16 10:10:59 larrylap kernel: Modules linked in: [...]
> May 16 10:10:59 larrylap kernel: Pid: 1684, comm: b43 Not tainted 2.6.26-rc2-wl-07884-g5d3790d-dirty #3
> May 16 10:10:59 larrylap kernel: RIP: 0010:[<ffffffffa0159eb1>] [<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/0x53e
> May 16 10:10:59 larrylap kernel: RSP: 0018:ffff8100b9fdbb50  EFLAGS: 00010246
> May 16 10:10:59 larrylap kernel: RAX: 0000000000000000 RBX: ffff8100b96ef410 RCX: 0000000000000000
> May 16 10:10:59 larrylap kernel: RDX: ffff810037b88000 RSI: 0000000000000000 RDI: ffff8100b96ef42e
> May 16 10:10:59 larrylap kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8100b8ee7780
> May 16 10:10:59 larrylap kernel: R10: ffff8100b8a3e480 R11: ffff8100b8a3e480 R12: ffff810037b88b90
> May 16 10:10:59 larrylap kernel: R13: ffff8100b8ee7780 R14: ffff8100b96ef42c R15: ffffffffa01bbb70
> May 16 10:10:59 larrylap kernel: FS:  00007fab6fcac700(0000) GS:ffffffff8054e000(0000) knlGS:00000000f6398b10
> May 16 10:10:59 larrylap kernel: CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> May 16 10:10:59 larrylap kernel: CR2: 00000000000000c0 CR3: 00000000b8257000 CR4: 00000000000006e0
> May 16 10:10:59 larrylap kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> May 16 10:10:59 larrylap kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> May 16 10:10:59 larrylap kernel: Process b43 (pid: 1684, threadinfo ffff8100b9fda000, task ffff8100b871e780)
> May 16 10:10:59 larrylap kernel: Stack:  ffffffff8028c3d0 ffff810037b88000 ffffffff8028bdc1 0000000037b88be0
> May 16 10:10:59 larrylap kernel:  ffff810037b88c24 0000000000000000 30373a61313a3030 623a61623a36343a
> May 16 10:10:59 larrylap kernel:  ffff8100bb6b0031 ffff8100b9fdbd20 ffff8100b878a034 0000000000000002
> May 16 10:10:59 larrylap kernel: Call Trace:
> May 16 10:10:59 larrylap kernel:  [<ffffffff8028c3d0>] kfree+0x1d6/0x1e5
> May 16 10:10:59 larrylap kernel:  [<ffffffff8028bdc1>] kmem_cache_free+0x19b/0x1aa
> May 16 10:10:59 larrylap kernel:  [<ffffffffa015a816>] :mac80211:ieee80211_sta_rx_queued_mgmt+0x54b/0xf0b
> May 16 10:10:59 larrylap kernel:  [<ffffffffa0162376>] :mac80211:ieee80211_master_start_xmit+0x3af/0x3cc
> May 16 10:10:59 larrylap kernel:  [<ffffffff802377ef>] local_bh_enable_ip+0xd0/0xd7
> May 16 10:10:59 larrylap kernel:  [<ffffffff8024e48c>] mark_held_locks+0x58/0x72
> May 16 10:10:59 larrylap kernel:  [<ffffffff803f8fb7>] _spin_unlock_irqrestore+0x3f/0x46
> May 16 10:10:59 larrylap kernel:  [<ffffffff8024e61c>] trace_hardirqs_on+0xef/0x113
> May 16 10:10:59 larrylap kernel:  [<ffffffffa015b912>] :mac80211:ieee80211_sta_work+0xb6/0x738
> May 16 10:10:59 larrylap kernel:  [<ffffffff803f8e94>] _spin_unlock_irq+0x24/0x27
> May 16 10:10:59 larrylap kernel:  [<ffffffff8024e61c>] trace_hardirqs_on+0xef/0x113
> May 16 10:10:59 larrylap kernel:  [<ffffffffa015b85c>] :mac80211:ieee80211_sta_work+0x0/0x738
> May 16 10:10:59 larrylap kernel:  [<ffffffff8024162b>] run_workqueue+0xe3/0x1ec
> May 16 10:10:59 larrylap kernel:  [<ffffffff80242115>] worker_thread+0xdc/0xeb
> May 16 10:10:59 larrylap kernel:  [<ffffffff80244b67>] autoremove_wake_function+0x0/0x2e
> May 16 10:10:59 larrylap kernel:  [<ffffffff80242039>] worker_thread+0x0/0xeb
> May 16 10:10:59 larrylap kernel:  [<ffffffff80244a4b>] kthread+0x47/0x74
> May 16 10:10:59 larrylap kernel:  [<ffffffff803f8921>] trace_hardirqs_on_thunk+0x35/0x3a
> May 16 10:10:59 larrylap kernel:  [<ffffffff8020ccf8>] child_rip+0xa/0x12
> May 16 10:10:59 larrylap kernel:  [<ffffffff8020c40f>] restore_args+0x0/0x30
> May 16 10:10:59 larrylap kernel:  [<ffffffff802448c2>] kthreadd+0x17f/0x1a4
> May 16 10:10:59 larrylap kernel:  [<ffffffff80244a04>] kthread+0x0/0x74
> May 16 10:10:59 larrylap kernel:  [<ffffffff8020ccee>] child_rip+0x0/0x12
> May 16 10:10:59 larrylap kernel:
> May 16 10:10:59 larrylap kernel:
> May 16 10:10:59 larrylap kernel: Code: 00 49 89 c6 49 8b 84 24 b8 00 00 00 49 
> 8d 7e 02 fc 41 88 46 01 49 8b 8c 24 b8 00 00 00 48 8b 74 24 20 f3 a4 31 f6 48 
> 8b 4c 24 28 <4c> 8b 89 c0 00 00 00 48 c7 44 24 10 00 00 00 00 eb 4a 48 8b 5c
> May 16 10:10:59 larrylap kernel: RIP  [<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/0x53e
> May 16 10:10:59 larrylap kernel: RIP  [<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/0x53e
> May 16 10:10:59 larrylap kernel:  RSP <ffff8100b9fdbb50>
> May 16 10:10:59 larrylap kernel: CR2: 00000000000000c0
> May 16 10:10:59 larrylap kernel: ---[ end trace 0010c8900b24b09d ]---

I can definitely not place this, though.

Can you try to find out what code this corresponds to?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: NULL pointer in mac80211:ieee80211_associate
  2008-05-16 21:47 ` Johannes Berg
@ 2008-05-16 23:05   ` Larry Finger
  2008-05-16 23:09     ` Johannes Berg
  0 siblings, 1 reply; 6+ messages in thread
From: Larry Finger @ 2008-05-16 23:05 UTC (permalink / raw)
  To: Johannes Berg; +Cc: wireless

Johannes Berg wrote:
> Larry,
> 
>> I think this report is new. If it is a duplicate, I apologize for any noise. 
> 
> I've definitely not seen it before, thanks.
> 
>> The system was last booted at 18:02 on May 15. Until 10:10:58, everything 
>> seemed normal. Then a reason 3 deauthentication arrived, and the following 
>> ensued:
> 
> Actually, the deauthentication is what you're sending, see
> ieee80211_sta_deauthenticate (in mlme.c). Any idea why it would be sent?
> Did you kill wpa_supplicant or something similar?

No, I was just working at the reverse engineering for the LP-PHY code without 
using the network. When I went to check for new E-mail, I found that the b43 
device was off line. Whne it wouldn't reconnect, I found the error message in 
the logs.

> In any case, we wouldn't expect to get a deauth with reason 15
> (WLAN_REASON_4WAY_HANDSHAKE_TIMEOUT) then. Hmm. Maybe that's why
> wpa_supplicant was trying to disassociate as well?
> 
> Still, we should of course not crash :)
> 
>> May 16 10:10:58 larrylap kernel: eth1: deauthenticate(reason=3)
>> May 16 10:10:58 larrylap kernel: eth1: RX deauthentication from 00:1a:70:46:ba:b1 (reason=15)
>> May 16 10:10:58 larrylap kernel: eth1: deauthenticated
>> May 16 10:10:58 larrylap avahi-daemon[3042]: Withdrawing address record for 
>> 192.168.1.122 on eth1.
>> May 16 10:10:58 larrylap avahi-daemon[3042]: Leaving mDNS multicast
>>   group on interface eth1.IPv4 with address 192.168.1.122.
>> May 16 10:10:58 larrylap avahi-daemon[3042]: Interface eth1.IPv4 no longer 
>> relevant for mDNS.
>> May 16 10:10:59 larrylap kernel: eth1: authenticate with AP 00:1a:70:46:ba:b1
>> May 16 10:10:59 larrylap kernel: eth1: RX authentication from 
>> 00:1a:70:46:ba:b1 (alg=0 transaction=2 status=0)
>> May 16 10:10:59 larrylap kernel: eth1: authenticated
>> May 16 10:10:59 larrylap kernel: eth1: associate with AP 00:1a:70:46:ba:b1
>> May 16 10:10:59 larrylap kernel: BUG: unable to handle kernel NULL pointer dereference at 00000000000000c0
>> May 16 10:10:59 larrylap kernel: IP: [<ffffffffa0159eb1>] :mac80211:ieee80211_associate+0x2ba/0x53e
>> May 16 10:10:59 larrylap kernel: PGD b8258067 PUD b8259067 PMD 0
>> May 16 10:10:59 larrylap kernel: Oops: 0000 [1] SMP
> 
> I can definitely not place this, though.
> 
> Can you try to find out what code this corresponds to?

 From objdump with line numbers, it occurs at "for (i = 0; i < 
bss->supp_rates_len; i++) {" in ieee80211_compatible_rates, which I think is 
entered from ieee80211_send_assoc. It seems that bss is NULL. For testing, I 
have placed a WARN_ON(!bss) statement just before the for loop.

Larry


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: NULL pointer in mac80211:ieee80211_associate
  2008-05-16 23:05   ` Larry Finger
@ 2008-05-16 23:09     ` Johannes Berg
  2008-05-17 16:50       ` Helmut Schaa
  0 siblings, 1 reply; 6+ messages in thread
From: Johannes Berg @ 2008-05-16 23:09 UTC (permalink / raw)
  To: Larry Finger; +Cc: wireless, Helmut Schaa

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]


> > Can you try to find out what code this corresponds to?
> 
>  From objdump with line numbers, it occurs at "for (i = 0; i < 
> bss->supp_rates_len; i++) {" in ieee80211_compatible_rates, which I think is 
> entered from ieee80211_send_assoc. It seems that bss is NULL. For testing, I 
> have placed a WARN_ON(!bss) statement just before the for loop.

That looks plausible. Helmut, any ideas how to avoid this? Skip the
compatible rates test completely and use all rates in this situation?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: NULL pointer in mac80211:ieee80211_associate
  2008-05-16 23:09     ` Johannes Berg
@ 2008-05-17 16:50       ` Helmut Schaa
  2008-05-17 16:56         ` Johannes Berg
  0 siblings, 1 reply; 6+ messages in thread
From: Helmut Schaa @ 2008-05-17 16:50 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Larry Finger, wireless

Am Sa 17 Mai 2008 01:09:57 CEST schrieb Johannes Berg  
<johannes@sipsolutions.net>:

>> > Can you try to find out what code this corresponds to?
>>
>>  From objdump with line numbers, it occurs at "for (i = 0; i <
>> bss->supp_rates_len; i++) {" in ieee80211_compatible_rates, which I think is
>> entered from ieee80211_send_assoc. It seems that bss is NULL. For testing, I
>> have placed a WARN_ON(!bss) statement just before the for loop.
>
> That looks plausible. Helmut, any ideas how to avoid this? Skip the
> compatible rates test completely and use all rates in this situation?

Yes, that's most likely the best solution for it. If we do not have a  
bss at this point we cannot adjust the rates anyway. Should I prepare  
a patch?

Helmut

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: NULL pointer in mac80211:ieee80211_associate
  2008-05-17 16:50       ` Helmut Schaa
@ 2008-05-17 16:56         ` Johannes Berg
  0 siblings, 0 replies; 6+ messages in thread
From: Johannes Berg @ 2008-05-17 16:56 UTC (permalink / raw)
  To: Helmut Schaa; +Cc: Larry Finger, wireless

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Sat, 2008-05-17 at 18:50 +0200, Helmut Schaa wrote:
> Am Sa 17 Mai 2008 01:09:57 CEST schrieb Johannes Berg  
> <johannes@sipsolutions.net>:
> 
> >> > Can you try to find out what code this corresponds to?
> >>
> >>  From objdump with line numbers, it occurs at "for (i = 0; i <
> >> bss->supp_rates_len; i++) {" in ieee80211_compatible_rates, which I think is
> >> entered from ieee80211_send_assoc. It seems that bss is NULL. For testing, I
> >> have placed a WARN_ON(!bss) statement just before the for loop.
> >
> > That looks plausible. Helmut, any ideas how to avoid this? Skip the
> > compatible rates test completely and use all rates in this situation?
> 
> Yes, that's most likely the best solution for it. If we do not have a  
> bss at this point we cannot adjust the rates anyway. Should I prepare  
> a patch?

Please do, thanks.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-05-17 16:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-16 21:28 NULL pointer in mac80211:ieee80211_associate Larry Finger
2008-05-16 21:47 ` Johannes Berg
2008-05-16 23:05   ` Larry Finger
2008-05-16 23:09     ` Johannes Berg
2008-05-17 16:50       ` Helmut Schaa
2008-05-17 16:56         ` Johannes Berg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).