Hi Brian, > > IIUC, it's not exactly a nested lock, but a lock inversion issue. > > #1 > NL80211_CMD_GET_INTERFACE thread is holding rtnl lock and later waiting > on one of its HostCmd_CMD_* to complete > > In the meantime: > #2 > a EVENT_BG_SCAN_STOPPED is queued, and it grabs the rtnl lock > > Because events are served on the same thread as commands, you get #1 > waiting on #2, which is waiting on the lock held in #1. i.e., ABBA. > > The way to resolve this is to either move event processing to a different > thread than command processing (that looks it would be very difficult to do > correctly, given the ossified structure of your driver; but that might be a wise > move in the long term)... > ...or else maybe you could defer this specific piece of work to its own thread. > That might require yet another workqueue? Yes, with current design we should be doing this. We will try to get this change. > > Anyway, the key point is that you really don't want to hold rtnl_lock in your > main workqueue, or in any other way that might block the rest of the > operation of your driver. Ok. Thanks for clarifying the scenario. I missed out the fact that same thread is blocked by the lock. > > Brian
