Search Linux Wireless

Re: mac80211: sta info locking

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

 



On Tue, Feb 26, 2008 at 1:23 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
>
>  > >  > The problem is that RX a TX BA establishments usually happens
>  > >  > concurrently for single STA, those are independent state machines.  We
>  > >  > have to review this carefully before spinlokcs are removed.
>  > >
>  > >  I wouldn't want to remove them, but it seems overkill two have two
>  > >  spinlocks. What I'd like to do is remove the ampdu tx, ampdu rx and mesh
>  > >  spinlocks and instead use just a single one for all three uses, and then
>  > >  use that one to protect the flags as well.
>  > >
>  > >  It seems to me that even if the RX/TX BA establishment is happening
>  > >  concurrently then it's still serialized by the frames on the air so
>  > >  ultimately can't actually happen on different CPUs so the lock won't be
>  > >  contended.
>  >
>  > I'm not sure about this, this is quite gentle and requires heavy
>  > testing.  I'll try to review this with Ron tomorrow and all other
>  > changes you've suggested.
>
>  Thanks. Yes, I do realize that this is a bit intrusive. On the other
>  hand, I can't see the code holding the spinlock for longer code/periods
>  of time (nor should it). Or do you think the driver is allowed to call
>  into the AMPDU TX setup path while being called from the AMPDU RX setup
>  path? That would be a bit weird.
>

TX and RX BA sessions are triggered from different threads of
execution namely rate scaling and RX path. The protected sections are
quite long IMHO including call outs to underlying driver. It is very
likely that both sides decides for BA session at the same times.

>  > Do you have any setup to check your these changes?
>
>  Unfortunately not quite yet. I have an 11n AP now though, but broke of
>  one of the antennas, I'll need to see how well it works.

That's bad 11n is too sensitive on antennas setup.

>
>  > Currently there is known possible deadlock when unloading driver while
>  > heavy HT traffic. This is happening while trearing down BA session. I
>  > need to solve this as well.
>
>  Interesting, where does it deadlock?

IIRC there is nice loop including queue lock need to dig the
description tomorrow to satisfy your curiosity.


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