Hi, So maybe this outlines my thinking a bit better. I'm adding two new bits of infrastructure to workqueues, with the end result that a 'special' workqueue can be completely serialized with other code even as far as execution of a work is concerned. The real advantage of this isn't the locking simplification you see in patch 4, the real advantage is that mac80211 will later be able to use that workqueue, and even if it's called from cfg80211 where the wiphy_lock() is already held it can still properly clean up its own work structs. This is a thing that in the passed caused the huge proliferation of locks in mac80211, which really aren't needed since (a) it also uses an ordered workqueue, and (b) all the drivers have just their own underlying single lock to access the device. Which makes sense, really, there's only one device. As a consequence, this will allow us to radically simplify locking, even with drivers not needing any locks, since all (control!) paths will hold one mutex. The second patch in this series is sort of not necessary, we could just make our own worker infrastructure in cfg80211 and hold the lock there, but it seemed simple enough to at least throw it out there; if you don't like it, I can just rework without it, but maybe other subsystems may have some ideas along the same lines in the future. Even the first patch isn't strictly needed, I previously posted a version of the third patch without it, but again it seemed pretty simple here and less overhead. An alternative overall might be to just get rid of both of those patches, and put a separate work list into cfg80211, and just execute those work structs off a single "real" work struct on the workqueue, with appropriate locking and exclusion, but that builds very local infrastructure where this might be useful to others too? Anyway, just an RFC right now. As described above the real meat would only kick in later when we push this through to mac80211 and even drivers. johannes
