On Sat, 2010-01-23 at 19:19 +0100, Michael Buesch wrote:
> > > - mutex_lock(&wl->mutex);
> > > + if (!mutex_is_locked(&wl->mutex)) {
> >
> > I think this might be because update_tkip_key is called from within the
> > RX path, so it's probably not even safe to use mutexes to start with?
>
> Well, if mac80211 does a callback into the driver on behalf of a driver call,
> that is broken design. It would break for all locks, not just mutexes.
Yes, but
> We should probably switch back to ieee80211_rx_irqsafe to workaround these
> circular locking problems.
Actually you can't, because you can't acquire the mutex here since we're
in an atomic section. So relying on it being already locked is probably
safer. However, you can't actually sleep anyway...
the proper fix would be to delay the call in mac80211 to a work.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
