2013-02-25 18:18:18

by Fabio Rossi

[permalink] [raw]
Subject: regression with kernel 3.8

I'm using the latest wireless-testing.git and I have found a regression with
kernel 3.8. I don't know if this is related to the driver I'm using (ath5k) but
I have bisected the problem to the commit
6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue handling
during scans). Basically the authentication and association infos don't appear
anymore in the kernel logs during a connection to my access point.

Tell me what you need to further debug the issue and solve the problem.

Fabio



2013-02-26 19:13:51

by Seth Forshee

[permalink] [raw]
Subject: Re: regression with kernel 3.8

On Mon, Feb 25, 2013 at 11:38:38PM +0100, Johannes Berg wrote:
> On Mon, 2013-02-25 at 13:26 -0600, Seth Forshee wrote:
> > On Mon, Feb 25, 2013 at 07:18:16PM +0100, Fabio Rossi wrote:
> > > I'm using the latest wireless-testing.git and I have found a regression with
> > > kernel 3.8. I don't know if this is related to the driver I'm using (ath5k) but
> > > I have bisected the problem to the commit
> > > 6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue handling
> > > during scans). Basically the authentication and association infos don't appear
> > > anymore in the kernel logs during a connection to my access point.
> > >
> > > Tell me what you need to further debug the issue and solve the problem.
> >
> > That patch is after 3.8.
> >
> > Johannes, this looks like a problem with the changes you made when
> > applying that patch. I really should have tested the result before now.
>
> Hmm, crap. Sorry about that!
>
> > I think the off-channel frames are getting queued rather than passed
> > down to the driver, which obviously isn't what we want. I'll get this
> > fixed.
>
> I saw you posted it, I'll take a closer look tomorrow morning.

Have you had a chance to look at the patch yet? I think we ought to try
and get this fixed pretty quickly.

Seth


2013-02-25 19:26:33

by Seth Forshee

[permalink] [raw]
Subject: Re: regression with kernel 3.8

On Mon, Feb 25, 2013 at 07:18:16PM +0100, Fabio Rossi wrote:
> I'm using the latest wireless-testing.git and I have found a regression with
> kernel 3.8. I don't know if this is related to the driver I'm using (ath5k) but
> I have bisected the problem to the commit
> 6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue handling
> during scans). Basically the authentication and association infos don't appear
> anymore in the kernel logs during a connection to my access point.
>
> Tell me what you need to further debug the issue and solve the problem.

That patch is after 3.8.

Johannes, this looks like a problem with the changes you made when
applying that patch. I really should have tested the result before now.

I think the off-channel frames are getting queued rather than passed
down to the driver, which obviously isn't what we want. I'll get this
fixed.

Seth


2013-02-25 22:38:41

by Johannes Berg

[permalink] [raw]
Subject: Re: regression with kernel 3.8

On Mon, 2013-02-25 at 13:26 -0600, Seth Forshee wrote:
> On Mon, Feb 25, 2013 at 07:18:16PM +0100, Fabio Rossi wrote:
> > I'm using the latest wireless-testing.git and I have found a regression with
> > kernel 3.8. I don't know if this is related to the driver I'm using (ath5k) but
> > I have bisected the problem to the commit
> > 6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue handling
> > during scans). Basically the authentication and association infos don't appear
> > anymore in the kernel logs during a connection to my access point.
> >
> > Tell me what you need to further debug the issue and solve the problem.
>
> That patch is after 3.8.
>
> Johannes, this looks like a problem with the changes you made when
> applying that patch. I really should have tested the result before now.

Hmm, crap. Sorry about that!

> I think the off-channel frames are getting queued rather than passed
> down to the driver, which obviously isn't what we want. I'll get this
> fixed.

I saw you posted it, I'll take a closer look tomorrow morning.

johannes


2013-02-25 20:58:10

by Seth Forshee

[permalink] [raw]
Subject: [PATCH] mac80211: Ensure off-channel frames don't get queued

Commit 6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue
handling during scans) contains a bug that causes off-channel frames to
get queued when they should be handed down to the driver for transmit.
Prevent this from happening.

Reported-by: Fabio Rossi <[email protected]>
Signed-off-by: Seth Forshee <[email protected]>
---

Fabio, this patch should fix the problem. Can you verify?

Johannes, this prevents the off-channel frames from getting queued
without affecting the fast path. It does however make the indentation
awfully deep ...

net/mac80211/tx.c | 56 +++++++++++++++++++++++++++++------------------------
1 file changed, 31 insertions(+), 25 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5b9602b..b1296e7 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1231,34 +1231,40 @@ static bool ieee80211_tx_frags(struct ieee80211_local *local,
if (local->queue_stop_reasons[q] ||
(!txpending && !skb_queue_empty(&local->pending[q]))) {
if (unlikely(info->flags &
- IEEE80211_TX_INTFL_OFFCHAN_TX_OK &&
- local->queue_stop_reasons[q] &
- ~BIT(IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL))) {
+ IEEE80211_TX_INTFL_OFFCHAN_TX_OK)) {
+ if (local->queue_stop_reasons[q] &
+ ~BIT(IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL)) {
+ /*
+ * Drop off-channel frames if queues
+ * are stopped for any reason other
+ * than off-channel operation. Never
+ * queue them.
+ */
+ spin_unlock_irqrestore(
+ &local->queue_stop_reason_lock,
+ flags);
+ ieee80211_purge_tx_queue(&local->hw,
+ skbs);
+ return true;
+ }
+ } else {
+
/*
- * Drop off-channel frames if queues are stopped
- * for any reason other than off-channel
- * operation. Never queue them.
+ * Since queue is stopped, queue up frames for
+ * later transmission from the tx-pending
+ * tasklet when the queue is woken again.
*/
- spin_unlock_irqrestore(
- &local->queue_stop_reason_lock, flags);
- ieee80211_purge_tx_queue(&local->hw, skbs);
- return true;
+ if (txpending)
+ skb_queue_splice_init(skbs,
+ &local->pending[q]);
+ else
+ skb_queue_splice_tail_init(skbs,
+ &local->pending[q]);
+
+ spin_unlock_irqrestore(&local->queue_stop_reason_lock,
+ flags);
+ return false;
}
-
- /*
- * Since queue is stopped, queue up frames for later
- * transmission from the tx-pending tasklet when the
- * queue is woken again.
- */
- if (txpending)
- skb_queue_splice_init(skbs, &local->pending[q]);
- else
- skb_queue_splice_tail_init(skbs,
- &local->pending[q]);
-
- spin_unlock_irqrestore(&local->queue_stop_reason_lock,
- flags);
- return false;
}
spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);

--
1.7.9.5


2013-02-26 20:16:55

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] mac80211: Ensure off-channel frames don't get queued

On Mon, 2013-02-25 at 14:58 -0600, Seth Forshee wrote:
> Commit 6c17b77b67587b9f9e3070fb89fe98cef3187131 (mac80211: Fix tx queue
> handling during scans) contains a bug that causes off-channel frames to
> get queued when they should be handed down to the driver for transmit.
> Prevent this from happening.
>
> Reported-by: Fabio Rossi <[email protected]>
> Signed-off-by: Seth Forshee <[email protected]>
> ---
>
> Fabio, this patch should fix the problem. Can you verify?
>
> Johannes, this prevents the off-channel frames from getting queued
> without affecting the fast path. It does however make the indentation
> awfully deep ...

Ugh .. I do see the bug, but the indentation is crap. I'll apply this
anyway, and then we can sort it out later.

johannes