| Message ID | 1248711120.6965.6.camel@mj (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, 2009-07-27 at 12:12 -0400, Pavel Roskin wrote: > + if (!(info->flags & IEEE80211_TX_INTFL_NEED_TXPROCESSING)) > + continue; P.S. ieee80211_tx_pending_skb() actually checks IEEE80211_TX_INTFL_NEED_TXPROCESSING and doesn't use sdata in that case. Perhaps we could use skb->dev instead of sdata->dev in that case. Also, the existence of ieee80211_tx_pending_skb() doesn't seem justified in its present form. It's a piece of ieee80211_tx_pending() that calculates the same variables and does the checks that the caller should be doing. I would just integrate it into ieee80211_tx_pending(). If the result is too complex, we could split it in a more logical way.
On Mon, 2009-07-27 at 12:12 -0400, Pavel Roskin wrote: > On Mon, 2009-07-27 at 18:02 +0200, Johannes Berg wrote: > > > Actually, you're using ath5k, right? So we can see what > > info->control.vif points to after ath5k has used the skb, because > > apparently it's a valid pointer at least, just not a real vif pointer > > any more. > > I'm using ath9k. > > Here's something interesting I have found. sdata->dev is valid if > info->flags is 0x14091 and not valid if it's 0x12091. > > 0x4000 is IEEE80211_TX_INTFL_NEED_TXPROCESSING and 0x2000 is > IEEE80211_TX_INTFL_RCALGO. > > This patch prevents any panics. Moreover, I get a connection with the > correct PSK. Ok. So the question is where that skb is coming from that's causing the issues (your patch leaks it btw) johannes
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 75604cd..dd1fa8b 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -1889,6 +1889,9 @@ void ieee80211_tx_pending(unsigned long data) struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); struct ieee80211_sub_if_data *sdata; + if (!(info->flags & IEEE80211_TX_INTFL_NEED_TXPROCESSING)) + continue; + if (WARN_ON(!info->control.vif)) { kfree_skb(skb); continue;