From: Luca Coelho <luca@coelho.fi>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless@vger.kernel.org, johannes@sipsolutions.net
Subject: Re: [PATCH v2 1/4] mac80211: fix CSA tx queue locking
Date: Mon, 24 Mar 2014 14:25:44 +0200 [thread overview]
Message-ID: <1395663944.4515.45.camel@dubbel> (raw)
In-Reply-To: <1395408675-26013-2-git-send-email-michal.kazior@tieto.com>
On Fri, 2014-03-21 at 14:31 +0100, Michal Kazior wrote:
> It was possible for tx queues to be stuck locked
> if AP CSA finalization failed.
I think it's clearer if you say "tx queue stopping" or something to
avoid confusion with the word "locking". Same applies to the commit
subject.
[...]
> It is still possible to have tx queues stopped
> after CSA failure but as soon as offending
> interfaces are stopped from userspace (stop_ap or
> ifdown) tx queues are woken up properly.
Isn't there any way to avoid this? I mean, if you have identified some
cases, why not fix them too? :)
[...]
> @@ -3092,8 +3122,13 @@ void ieee80211_csa_finalize_work(struct work_struct *work)
> goto unlock;
>
> ieee80211_csa_finalize(sdata);
> + if (!ieee80211_csa_needs_block_tx(local))
> + ieee80211_wake_queues_by_reason(&local->hw,
> + IEEE80211_MAX_QUEUE_MAP,
> + IEEE80211_QUEUE_STOP_REASON_CSA);
This should remain inside ieee80211_csa_finalize() as it was before,
because otherwise you won't wake up the queues in case of an immediate
switch. Look at the bottom of your new __ieee80211_channel_switch(),
we call ieee80211_csa_finalize() directly if the beacon didn't change.
Actually, in the beacon-didn't-change case, we should probably not even
stop the queues?
[...]
> @@ -3271,15 +3307,15 @@ int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
> return err;
>
> sdata->csa_radar_required = params->radar_required;
> -
> - if (params->block_tx)
> - ieee80211_stop_queues_by_reason(&local->hw,
> - IEEE80211_MAX_QUEUE_MAP,
> - IEEE80211_QUEUE_STOP_REASON_CSA);
> -
> sdata->csa_chandef = params->chandef;
> + sdata->csa_block_tx = params->block_tx;
> sdata->vif.csa_active = true;
>
> + if (sdata->csa_block_tx)
> + ieee80211_wake_queues_by_reason(&local->hw,
> + IEEE80211_MAX_QUEUE_MAP,
> + IEEE80211_QUEUE_STOP_REASON_CSA);
Shouldn't this be *stop* queues?
You can call ieee80211_stop_queues_by_reason() even if it is already
stopped for this reason, but maybe you could call
ieee80211_csa_needs_block_tx() here to avoid eventually calling it
multiple times. I think this is also a bit more consistent.
if(ieee80211_csa_needs_block_tx(...))
ieee80211_stop_queues_by_reason(...)
[...]
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index bbc2175..2ca1472 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -952,15 +952,18 @@ static void ieee80211_chswitch_work(struct work_struct *work)
> /* XXX: shouldn't really modify cfg80211-owned data! */
> ifmgd->associated->channel = sdata->csa_chandef.chan;
>
> - /* XXX: wait for a beacon first? */
> - ieee80211_wake_queues_by_reason(&local->hw,
> - IEEE80211_MAX_QUEUE_MAP,
> - IEEE80211_QUEUE_STOP_REASON_CSA);
> -
> ieee80211_bss_info_change_notify(sdata, changed);
>
> out:
> + mutex_lock(&local->mtx);
> sdata->vif.csa_active = false;
> + /* XXX: wait for a beacon first? */
> + if (!ieee80211_csa_needs_block_tx(local))
> + ieee80211_wake_queues_by_reason(&local->hw,
> + IEEE80211_MAX_QUEUE_MAP,
> + IEEE80211_QUEUE_STOP_REASON_CSA);
> + mutex_unlock(&local->mtx);
Instead of moving this to the out label, I guess the right place for it
would be in ieee80211_set_disassoc(). Then we would catch the
csa_connection_drop_work cases plus a few other cases that seem to be
missing(?).
[...]
> @@ -1077,12 +1080,16 @@ ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
> mutex_unlock(&local->chanctx_mtx);
>
> sdata->csa_chandef = csa_ie.chandef;
> +
> + mutex_lock(&local->mtx);
> sdata->vif.csa_active = true;
> + sdata->csa_block_tx = csa_ie.mode;
>
> - if (csa_ie.mode)
> + if (sdata->csa_block_tx)
> ieee80211_stop_queues_by_reason(&local->hw,
> - IEEE80211_MAX_QUEUE_MAP,
> - IEEE80211_QUEUE_STOP_REASON_CSA);
> + IEEE80211_MAX_QUEUE_MAP,
> + IEEE80211_QUEUE_STOP_REASON_CSA);
> + mutex_unlock(&local->mtx);
Same thing as before, maybe it's more consistent to call
ieee80211_csa_needs_block_tx()?
[...]
> @@ -2035,10 +2043,14 @@ static void __ieee80211_disconnect(struct ieee80211_sub_if_data *sdata)
> WLAN_REASON_DISASSOC_DUE_TO_INACTIVITY,
> true, frame_buf);
> ifmgd->flags &= ~IEEE80211_STA_CSA_RECEIVED;
> +
> + mutex_lock(&local->mtx);
> sdata->vif.csa_active = false;
> - ieee80211_wake_queues_by_reason(&sdata->local->hw,
> + if (!ieee80211_csa_needs_block_tx(local))
> + ieee80211_wake_queues_by_reason(&local->hw,
> IEEE80211_MAX_QUEUE_MAP,
> IEEE80211_QUEUE_STOP_REASON_CSA);
> + mutex_unlock(&local->mtx);
As I said before, it's probably better to do this in
ieee80211_set_disassoc(). But maybe in a separate patch?
--
Luca.
next prev parent reply other threads:[~2014-03-24 12:25 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 14:26 [PATCH 0/4] mac80211/cfg80211: CSA fixes/cleanups Michal Kazior
2014-03-05 14:27 ` [PATCH 1/4] mac80211: fix CSA tx queue locking Michal Kazior
2014-03-10 16:27 ` Johannes Berg
2014-03-11 7:20 ` Michal Kazior
2014-03-11 13:19 ` Johannes Berg
2014-03-05 14:27 ` [PATCH 2/4] mac80211: split CSA finalize function Michal Kazior
2014-03-05 14:27 ` [PATCH 3/4] cfg80211: export interface stopping function Michal Kazior
2014-03-05 14:27 ` [PATCH 4/4] mac80211: disconnect iface if CSA unexpectedly fails Michal Kazior
2014-03-21 13:31 ` [PATCH v2 0/4] mac80211/cfg80211: CSA fixes/cleanups Michal Kazior
2014-03-21 13:31 ` [PATCH v2 1/4] mac80211: fix CSA tx queue locking Michal Kazior
2014-03-24 12:25 ` Luca Coelho [this message]
2014-03-24 12:58 ` Michal Kazior
2014-03-24 13:14 ` Luca Coelho
2014-03-21 13:31 ` [PATCH v2 2/4] mac80211: split CSA finalize function Michal Kazior
2014-03-21 13:31 ` [PATCH v2 3/4] cfg80211: export interface stopping function Michal Kazior
2014-03-24 13:56 ` Luca Coelho
2014-03-24 14:02 ` Michal Kazior
2014-03-24 14:32 ` Arend van Spriel
2014-03-24 14:52 ` Michal Kazior
2014-03-21 13:31 ` [PATCH v2 4/4] mac80211: disconnect iface if CSA unexpectedly fails Michal Kazior
2014-03-24 14:55 ` Luca Coelho
2014-03-25 7:46 ` Michal Kazior
2014-03-28 9:52 ` [PATCH v2 0/4] mac80211/cfg80211: CSA fixes/cleanups Johannes Berg
2014-03-31 9:57 ` [PATCH v3 " Michal Kazior
2014-03-31 9:57 ` [PATCH v3 1/4] mac80211: fix CSA tx queue locking Michal Kazior
2014-03-31 11:06 ` Luca Coelho
2014-03-31 11:40 ` Michal Kazior
2014-04-08 9:57 ` Johannes Berg
2014-03-31 9:57 ` [PATCH v3 2/4] mac80211: split CSA finalize function Michal Kazior
2014-03-31 11:20 ` Luca Coelho
2014-03-31 9:57 ` [PATCH v3 3/4] cfg80211: export interface stopping function Michal Kazior
2014-03-31 11:42 ` Luca Coelho
2014-03-31 9:57 ` [PATCH v3 4/4] mac80211: disconnect iface if CSA unexpectedly fails Michal Kazior
2014-03-31 11:45 ` Luca Coelho
2014-03-31 11:49 ` Michal Kazior
2014-04-08 10:02 ` Johannes Berg
2014-04-09 13:10 ` [PATCH v4 0/4] mac80211/cfg80211: CSA fixes/cleanups Michal Kazior
2014-04-09 13:10 ` [PATCH v4 1/4] mac80211: fix CSA tx queue locking Michal Kazior
2014-04-09 13:22 ` Luca Coelho
2014-04-09 13:25 ` Michal Kazior
2014-04-09 13:11 ` [PATCH v4 2/4] mac80211: split CSA finalize function Michal Kazior
2014-04-09 13:11 ` [PATCH v4 3/4] cfg80211: export interface stopping function Michal Kazior
2014-04-09 13:11 ` [PATCH v4 4/4] mac80211: disconnect iface if CSA unexpectedly fails Michal Kazior
2014-05-08 7:10 ` [PATCH v5] " Michal Kazior
2014-05-08 9:57 ` Johannes Berg
2014-05-06 13:15 ` [PATCH v4 0/4] mac80211/cfg80211: CSA fixes/cleanups Johannes Berg
2014-05-07 7:04 ` Michal Kazior
2014-05-07 8:59 ` Johannes Berg
2014-05-07 9:10 ` Michal Kazior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1395663944.4515.45.camel@dubbel \
--to=luca@coelho.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=michal.kazior@tieto.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.