On Tuesday 27 March 2007 01:05, Johannes Berg wrote: > Isn't there a race there when you remove interfaces and at the same time > __ieee80211_rx is running? I don't see anything that should stop that, > and if it happens we'll probably blow up pretty spectacularly with > accesses to a freed netdev, or even sending it frames... Well, IMHO __ieee80211_rx should be internal to mac80211 and not be exported. (Same goes for the IRQ-unsafe txstatus report). We can't (and we really don't want to) call synchronously into the stack from any driver. We want to defer the packet processing work to a tasklet. So we always want to call the _irqsafe functions. Why do we? Because of locking issues. 1) There's no need to hold the lowlevel driver IRQ spinlock while processing the packet in the upper layers. We want to release it. Easiest and non-racy way to do this is to use the _irqsafe function and its tasklet. 2) We want to prevent recursion back into the driver through a callback, which would result in lock recursion (we had these problems in softmac, as it is synchronous in most rx parts). So why do I tell you this? I think there's no way we can call __ieee80211_rx after removing the interface, as the tasklet should be stopped first. But someone should verify if I'm right here. But anyway, the driver shouldn't be able to call __ieee80211_rx after the device is down, too, as the driver has to make sure IRQs are stopped when the device is brought down. So we have kind of implicit locking here, but I think it's ok. -- Greetings Michael. - 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
