On 11/11/2010 06:37 PM, Johannes Berg wrote:
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.
There is a warning early in the boot from lockdep, not related to wifi.
I fear that is disabling all further lockdep warnings.
Thanks,
Ben
johannes
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
