On Tue, 2008-06-24 at 11:03 +0200, Ivo Van Doorn wrote: > > 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. ;) Ok :) > > 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. Oh, right, your work is actually taking the RTNL. We will not get the ->stop callback rtnl-free no matter what we do. And we can probably not even get it free of whatever lock we need for the netdev list either way... However, the interface iterator will simply not run at all if ->stop has already succeeded since no interfaces would be UP, so you don't really have to protect it against that, you only have to make sure it's not running when you unregister your hardware struct, and _that_ doesn't have the rtnl taken so you can use cancel_work_sync() there. > > 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. Agreed, care to prepare a patch? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
