On Thu, 2010-11-11 at 16:48 -0800, Ben Greear wrote:
> I have a potential scenario:
>
> The ieee80211_do_stop logic is called under RTNL, and it
> then calls flush_work().
>
> What if the worker thread is currently blocked on something like
> wireless_nlevent_process which tries to acquire rtnl?
>
> Wouldn't that cause a deadlock?
Only if Tejun's deadlock avoidance doesn't work -- we used to have a
separate kernel thread for mac80211 work including sdata->work which
never acquired the RTNL. Also, we have lockdep annotations for exactly
this kind of thing ("events" and "(linkwatch_work).work" in your held
locks output) that should catch this.
johannes
--
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
