[PATCH] mac80211: Recalculate channel-type on iface removal.

[PATCH] mac80211: Recalculate channel-type on iface removal.

[greearb]

From: Ben Greear <greearb@candelatech.com>

When a vif goes away, it could cause the super-chan
to be recalculated differently, so do that calculation
on iface removal.

Also, use WARN_ON_ONCE instead of WARN_ON if user has
ht40- stations in conjunction with ht40+.  It's not
really a kernel bug, just a mis-configuration of the
user's wifi environment.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 5b24740... ad9055d... M	net/mac80211/chan.c
:100644 100644 605c222... abf5f8e... M	net/mac80211/iface.c
 net/mac80211/chan.c  |    4 ++--
 net/mac80211/iface.c |    9 ++++++++-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5b24740..ad9055d 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -80,11 +80,11 @@ bool ieee80211_set_channel_type(struct ieee80211_local *local,
 			superchan = tmp->vif.bss_conf.channel_type;
 			break;
 		case NL80211_CHAN_HT40PLUS:
-			WARN_ON(superchan == NL80211_CHAN_HT40MINUS);
+			WARN_ON_ONCE(superchan == NL80211_CHAN_HT40MINUS);
 			superchan = NL80211_CHAN_HT40PLUS;
 			break;
 		case NL80211_CHAN_HT40MINUS:
-			WARN_ON(superchan == NL80211_CHAN_HT40PLUS);
+			WARN_ON_ONCE(superchan == NL80211_CHAN_HT40PLUS);
 			superchan = NL80211_CHAN_HT40MINUS;
 			break;
 		}
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 605c222..abf5f8e 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -382,6 +382,7 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
 	struct sk_buff *skb, *tmp;
 	u32 hw_reconf_flags = 0;
 	int i;
+	enum nl80211_channel_type orig_ct;
 
 	if (local->scan_sdata == sdata)
 		ieee80211_scan_cancel(local);
@@ -542,8 +543,14 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
 		hw_reconf_flags = 0;
 	}
 
+	/* Re-calculate channel-type, in case there are multiple vifs
+	 * on different channel types.
+	 */
+	orig_ct = local->_oper_channel_type;
+	ieee80211_set_channel_type(local, NULL, NL80211_CHAN_NO_HT);
+
 	/* do after stop to avoid reconfiguring when we stop anyway */
-	if (hw_reconf_flags)
+	if (hw_reconf_flags || (orig_ct != local->_oper_channel_type))
 		ieee80211_hw_config(local, hw_reconf_flags);
 
 	spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
-- 
1.7.2.3

Re: [PATCH] mac80211: Recalculate channel-type on iface removal.

[Johannes Berg]

On Mon, 2011-01-31 at 10:37 -0800, greearb@candelatech.com wrote:

> Also, use WARN_ON_ONCE instead of WARN_ON if user has
> ht40- stations in conjunction with ht40+.  It's not
> really a kernel bug, just a mis-configuration of the
> user's wifi environment.

But how did we end up here to start with -- shouldn't that have been
rejected?

johannes

Re: [PATCH] mac80211: Recalculate channel-type on iface removal.

[Ben Greear]

On 01/31/2011 10:44 AM, Johannes Berg wrote:
> On Mon, 2011-01-31 at 10:37 -0800, greearb@candelatech.com wrote:
>
>> Also, use WARN_ON_ONCE instead of WARN_ON if user has
>> ht40- stations in conjunction with ht40+.  It's not
>> really a kernel bug, just a mis-configuration of the
>> user's wifi environment.
>
> But how did we end up here to start with -- shouldn't that have been
> rejected?

The set-channel-type logic will complain, and I imagine the interfaces
will bounce around and attempt to re-associate, but I think it can
get into the mixed state.

Regardless of that, it may be something more mundane where we have
some HT-40 and HT-20 interfaces that can co-exist, but one of those
leaves.  We should still re-calculate in case their leaving changes
the super-chan calculation.

Thanks,
Ben

>
> johannes


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] mac80211: Recalculate channel-type on iface removal.

[Johannes Berg]

On Mon, 2011-01-31 at 10:48 -0800, Ben Greear wrote:
> On 01/31/2011 10:44 AM, Johannes Berg wrote:
> > On Mon, 2011-01-31 at 10:37 -0800, greearb@candelatech.com wrote:
> >
> >> Also, use WARN_ON_ONCE instead of WARN_ON if user has
> >> ht40- stations in conjunction with ht40+.  It's not
> >> really a kernel bug, just a mis-configuration of the
> >> user's wifi environment.
> >
> > But how did we end up here to start with -- shouldn't that have been
> > rejected?
> 
> The set-channel-type logic will complain, and I imagine the interfaces
> will bounce around and attempt to re-associate, but I think it can
> get into the mixed state.

I think we should try to avoid that.

> Regardless of that, it may be something more mundane where we have
> some HT-40 and HT-20 interfaces that can co-exist, but one of those
> leaves.  We should still re-calculate in case their leaving changes
> the super-chan calculation.

Yeah, no argument about that part of the patch.

johannes

Re: [PATCH] mac80211: Recalculate channel-type on iface removal.

[Ben Greear]

On 01/31/2011 10:57 AM, Johannes Berg wrote:
> On Mon, 2011-01-31 at 10:48 -0800, Ben Greear wrote:
>> On 01/31/2011 10:44 AM, Johannes Berg wrote:
>>> On Mon, 2011-01-31 at 10:37 -0800, greearb@candelatech.com wrote:
>>>
>>>> Also, use WARN_ON_ONCE instead of WARN_ON if user has
>>>> ht40- stations in conjunction with ht40+.  It's not
>>>> really a kernel bug, just a mis-configuration of the
>>>> user's wifi environment.
>>>
>>> But how did we end up here to start with -- shouldn't that have been
>>> rejected?
>>
>> The set-channel-type logic will complain, and I imagine the interfaces
>> will bounce around and attempt to re-associate, but I think it can
>> get into the mixed state.
>
> I think we should try to avoid that.

Ok.  I haven't actually tested that case yet.  It's possible
that we can't actually get in that case..but I haven't found
anything that prevents it while reading code.  Assuming there is a problem,
what would be the preferred fix?  Maybe force to NO_HT if an interface
tries to associate with HT40+/- mis-match?

Do you want me to repost this patch without the WARN_ON_ONCE
changes?

>> Regardless of that, it may be something more mundane where we have
>> some HT-40 and HT-20 interfaces that can co-exist, but one of those
>> leaves.  We should still re-calculate in case their leaving changes
>> the super-chan calculation.
>
> Yeah, no argument about that part of the patch.
>
> johannes

Thanks,
Ben

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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] mac80211: Recalculate channel-type on iface removal.

[Johannes Berg]

On Mon, 2011-01-31 at 11:04 -0800, Ben Greear wrote:

> >> The set-channel-type logic will complain, and I imagine the interfaces
> >> will bounce around and attempt to re-associate, but I think it can
> >> get into the mixed state.
> >
> > I think we should try to avoid that.
> 
> Ok.  I haven't actually tested that case yet.  It's possible
> that we can't actually get in that case..but I haven't found
> anything that prevents it while reading code.  Assuming there is a problem,
> what would be the preferred fix?  Maybe force to NO_HT if an interface
> tries to associate with HT40+/- mis-match?

I think ieee80211_enable_ht() checks this?

> Do you want me to repost this patch without the WARN_ON_ONCE
> changes?

For now, I think that'd be nicer. I suspect it doesn't actually matter
since the above means we can't get into that situation. Still we may
want WARN_ON_ONCE to prevent being flooded, but I guess it should be a
separate patch?

johannes