On Mon, Aug 29, 2011 at 11:13:10AM -0700, Thomas Pedersen wrote: > I meant to say "In addition to the above discussion, > ieee80211_tx_status() should not be called from interrupt context > anyway". > > > the very change the patch added. It's running in a bottom half > > though, not a hard irq. > > Even in a bottom half we're still in "interrupt" context, right? Yes, but my interpretation is that _irqsafe() in this case refers to hard irq context and not softirq context. So it's still atomic, but tx_status() does things like kfree_skb() directly instead of deferring that to another softirq. There are 3 contexts in Linux: process, softirq, and hardirq, and given that we have 3 corresponding tx_status functions (tx_status_ni, tx_status, tx_status_irqsafe), this interpretation makes sense, no? Someone correct me if I'm wrong here. It seems to me this patch warrants some discussion or some comments in the .h files about how drivers can be called back into themselves; otherwise it's very hard for a driver writer to get locking right without examining the stack. And dropping locks around various API calls means you have to validate the protected state when you get the lock back, it's not a panacea. -- Bob Copeland %% www.bobcopeland.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
