On Sat, 2008-09-27 at 21:51 +0200, Jiri Slaby wrote: > BUG: scheduling while atomic: iwl3945/0/1154/0x00000002 > [<ffffffff80257315>] synchronize_rcu+0x35/0x40 > [<ffffffff80551d17>] sta_info_destroy+0x47/0x110 > [<ffffffff80559156>] ieee80211_set_disassoc+0x146/0x250 > [<ffffffff805593d5>] ieee80211_sta_req_auth+0x85/0x90 > [<ffffffff8055b156>] ieee80211_notify_mac+0x56/0xa0 > [<ffffffffa0054663>] iwl3945_bg_alive_start+0x2f3/0x360 [iwl3945] > I don't know who is responsible here. Maybe ieee80211_notify_mac? Citing: > "It is illegal to block while in an RCU read-side critical section." from > rcu_read_lock comments, but synchronize_rcu() in __ieee80211_key_todo() > sleeps and few mutexes are locked and might_sleep() invoked on the path too. Yup, for sure. This is a combination of various things, when ieee80211_notify_mac was added ieee80211_sta_req_auth didn't destroy the sta info, later they fixed a different bug that started doing that and we all missed that it was called from here... We can fix this by using RTNL locking instead, not sure though that'll work because I don't know how iwl3945 calls this, I'll let Tomas deal with it. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
