Search Linux Wireless

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/17/2010 11:22 PM, Tejun Heo wrote:
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.

I understand your desire for a stack dump, but it appears that sysrq-t
isn't getting everything you want, for whatever reason.

Does my explanation of the rtnl deadlock that I posted near the beginning
of this thread (with some backtraces to back that up) make sense, or
are my assumptions invalid?

Thanks,
Ben


Thanks.



--
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


[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux