On 6/24/08, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2008-06-23 at 13:17 +0200, Ivo Van Doorn wrote: > >> Well it was caused by the recent introduction of the interface iterator. >> Question now is if we need to restrict the usage, remove the >> flush_workqueue, >> or change the locking in the interface iterator. :S > > Ouch. Any way you can use the atomic iterator there? No because of rt2500usb and rt73usb who need scheduling, and this bug is in exactly the same function as before where we had the scheduling while atomic problem when you introduced the atomic iterator. ;) > Or if not, can you use schedule_work and cancel_work_sync to take care > of things? I thought about that it cancel_work_sync will cause exactly the same problem, stop() holds the rtnl lock, rt2x00 work waits for rtnl lock, mac80211 calls stop(), rt2x00 waits until tasks are completed but one of those is still waiting on the rtnl lock. However I could use the non-synchronized version for cancelling the work and add a check to see if the work should be cancelled within the rtnl-protected area. > I would like to keep the mac80211 workqueue rtnl-free because > otherwise locking is going to get ugly. We need a big warning in mac80211.h then that tells that the non-atomic iterator or any other rtnl locking cannot be used in the mac80211 workqueue. Ivo -- 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
