>> > 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. True, but the race condition happens when ieee80211_stop() is called, and the rt2x00 work is triggered before before rt2x00->remove_interface() or rt2x00>stop() is called. when stop() is then called it cannot use cancel_work_sync() because the work structure is waiting until stop() has completed which will not end until cancel_work_sync() has completed. >> > 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? Sure, as soon as get home I'll write the patch. :) 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
