On 11/12/2010 12:08 PM, Luis R. Rodriguez wrote:
On Fri, Nov 12, 2010 at 12:07 PM,<greearb@xxxxxxxxxxxxxxx> wrote:
From: Ben Greear<greearb@xxxxxxxxxxxxxxx>
We cannot call flush_work here because we are holding
RTNL and the worker thread(s) that will be called upon to
do the flushing might already be running a piece of work
that is blocking on RTNL. That leads to deadlock and/or
OOM.
The ieee80211_iface_work method does nothing when sdata
is stopped (as it would be when the flush_work was called)
so it shouldn't be any big change to just cancel the work
entirely.
Signed-off-by: Ben Greear<greearb@xxxxxxxxxxxxxxx>
Is this a stable fix?
We didn't see this when testing against .36-ish
wireless-testing...
I can't do any useful testing against official .36 since it
doesn't have the ath5k multi-vif support.
I'm also not sure this patch 100% right, though
it does fix a very reproducible bug for me. I might be
missing some side-affect of cancelling instead of attempting
to flush the work queue, however, so we should wait for
input from whoever wrote that code in the first place...
Thanks,
Ben
--
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
