diff mbox

[1/3] mac80211: cooperate more with network namespaces

Message ID 1248718929.13118.3.camel@johannes.local (mailing list archive)
State Accepted, archived
Headers show

Commit Message

Johannes Berg July 27, 2009, 6:22 p.m. UTC 
On Mon, 2009-07-27 at 12:40 -0400, Pavel Roskin wrote:
> 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.

Nah, the bug is far more far-reaching, please see and try the patch
below.

> 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.

Well... go ahead and try to clean it up -- I don't think it's possible
due to the locking in ieee80211_tx_pending(), you definitely don't want
to have a function that must be called with a lock held and then drops
it in the middle only to re-acquire it. Just inlining it makes the whole
thing unreadable imo.

Anyway, please let me know if the patch below fixes things for you.
Again, one of these things where I'm sure there's an issue here, but I'm
not sure it's the one you're seeing.

johannes

---
 net/mac80211/main.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)



--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Pavel Roskin July 27, 2009, 7:02 p.m. UTC | #1 
On Mon, 2009-07-27 at 20:22 +0200, Johannes Berg wrote:

> Nah, the bug is far more far-reaching, please see and try the patch
> below.

Yes, it's working!  There are no crashes with correct and incorrect PSK.

I'm not very interested in making code look nicer if the real problem is
elsewhere.  I just assumed that the problem was where the panic
happened.
Johannes Berg July 27, 2009, 7:07 p.m. UTC | #2 
On Mon, 2009-07-27 at 15:02 -0400, Pavel Roskin wrote:
> On Mon, 2009-07-27 at 20:22 +0200, Johannes Berg wrote:
> 
> > Nah, the bug is far more far-reaching, please see and try the patch
> > below.
> 
> Yes, it's working!  There are no crashes with correct and incorrect PSK.

Good to know, thanks.

> I'm not very interested in making code look nicer if the real problem is
> elsewhere.  I just assumed that the problem was where the panic
> happened.

Right, just wanted to point it out anyway.

johannes
diff mbox

Patch

--- wireless-testing.orig/net/mac80211/main.c	2009-07-27 19:44:11.000000000 +0200
+++ wireless-testing/net/mac80211/main.c	2009-07-27 20:17:01.000000000 +0200
@@ -310,6 +310,31 @@  static void ieee80211_handle_filtered_fr
 {
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 
+	/*
+	 * XXX: This is temporary!
+	 *
+	 *	The problem here is that when we get here, the driver will
+	 *	quilte likely have pretty much overwritten info->control by
+	 *	using info->driver_data or info->rate_driver_data. Thus,
+	 *	when passing out the frame to the driver again, we would be
+	 *	passing completely bogus data since the driver would then
+	 *	expect a properly filled info->control. In mac80211 itself
+	 *	the same problem occurs, since we need info->control.vif
+	 *	internally.
+	 *
+	 *	To fix this, we should send the frame through TX processing
+	 *	again. However, it's not that simple, since the frame will
+	 *	have been software-encrypted (if applicable) already, and
+	 *	encrypting it again doesn't do much good. So to properly do
+	 *	that, we not only have to skip the actual 'raw' encryption
+	 *	(key selection etc. still has to be done!) but also the
+	 *	sequence number assignment since that impacts the crypto
+	 *	encapsulation, of course.
+	 *
+	 *	Hence, for now, fix the bug by just dropping the frame.
+	 */
+	goto drop;
+
 	sta->tx_filtered_count++;
 
 	/*
@@ -363,6 +388,7 @@  static void ieee80211_handle_filtered_fr
 		return;
 	}
 
+ drop:
 #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
 	if (net_ratelimit())
 		printk(KERN_DEBUG "%s: dropped TX filtered frame, "