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
