Re: [PATCH] mac80211: Fix deadlock in ieee80211_do_stop.

[Tejun Heo <tj@kernel.org>]

Hello, Johannes.

On 11/18/2010 08:07 AM, Johannes Berg wrote:
>> I see.  In the longer run tho, it would be much better to convert to
>> NRT workqueue.  The behavior would be more robust with much lower
>> latencies.
> 
> I really don't think it's possible without going to some scheme
> where we use a single work struct and kick off things out of it,
> or implement our own threading or similar things ...

I see.

> But why is this unreliable and/or high latency anyway?

Oh, no, it's not unreliable or high latency on workqueue side.  It's
just error prone for its users.  As there is only single executino
resource by definition, any single work can stall the whole queue and
it also is easy to create a deadlock by introducing circular
dependency.  For example, mac80211 uses system wq for restart work and
that's to avoid grabbing rtnl_lock from a work as that will introduce
a deadlock, right?  If you use non-ordered workqueues, you don't need
to worry about those artificial dependencies.

> It used to be just fine .. maybe this is one of the cases where we
> should actually be using a dedicated thread ...

Oh, trust me, that won't change anything.  If there's a bug in
workqueue (I don't think this is the case here tho), let's fix it.  If
mac80211 is somehow tripping a deadlock around single execution
resource, let's fix the culprit.  Okay?  At this point, all we need is
a proper task dump to see who's holding what where.

Thanks.

-- 
tejun