Re: mac80211 locking: tasklet vs. non-tasklet

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]


> >  With iwlwifi, however, there is a possibility that it invokes
> >  ieee80211_tx_status() on one CPU while mac80211's tasklet is processing
> >  another TX status that was submitted with ieee80211_tx_status_irqsafe().
> >  Tomas, I think you mentioned that the TX status processing can't
> >  actually ever call the non-irqsafe version, can we remove that call to
> >  be sure? :)
> 
> Actually alike athk also iwlwifi driver calls tx_status from a tasklet
> therfore the irqsafe can be removed. I've tested that it worked so far

Ok, fine too. Just the mixing is actually bad because of locking.

> However we added start_tx_ba_cb(_irqsafe) callback to get around AMPDU
> queues reordering
> In this case we have to use both handlers so I wonder where we have
> problem here as the same mechanism as tx_status is used.

I think the AMPDU stuff has its own spinlock around the fields it
accesses in those things. The thing with the tx status etc. is that it
uses no locking to update a few sta_info fields. If we added locking
around those accesses, mixing the two irqsafe/non-irqsafe versions would
be acceptable, but I don't see much point in that.

> In general I'm missing some asynchronous mechanism that driver can
> notify mac80211 about it's state.
> Except BA states there  is  for example  netif_carrier_off/on
> functionality in the driver level. It would be very useful for early
> notification of disconnection.  A disconnection can happen due to
> device resume or internal recoverable error. In this cases I would
> expect mac to try associate again upon such trigger.

I guess that's just missing. You can stop the queues but you can't tell
mac80211 that you reset the hw.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]