[PATCH] cfg80211: avoid intersection when applying custom reg

[PATCH] cfg80211: avoid intersection when applying custom reg

[Arik Nemtsov]

The custom-reg handling function can currently only add flags to a given
channel. This results in stale flags being left applied. In some cases
a channel was disabled and even the orig_flags were changed to reflect
this.

Previously the API was designed for a single invocation before wiphy
registration, so this didn't matter. The previous approach doesn't scale
well to self-managed regulatory devices, particularly when a more
permissive regdom is applied after a restrictive one.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
---
 net/wireless/reg.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 8941e1c..e4f4619 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1686,8 +1686,7 @@ static void handle_channel_custom(struct wiphy *wiphy,
 	if (IS_ERR(reg_rule)) {
 		REG_DBG_PRINT("Disabling freq %d MHz as custom regd has no rule that fits it\n",
 			      chan->center_freq);
-		chan->orig_flags |= IEEE80211_CHAN_DISABLED;
-		chan->flags = chan->orig_flags;
+		chan->flags |= IEEE80211_CHAN_DISABLED;
 		return;
 	}
 
@@ -1712,7 +1711,7 @@ static void handle_channel_custom(struct wiphy *wiphy,
 	chan->dfs_state = NL80211_DFS_USABLE;
 
 	chan->beacon_found = false;
-	chan->flags |= map_regdom_flags(reg_rule->flags) | bw_flags;
+	chan->flags = map_regdom_flags(reg_rule->flags) | bw_flags;
 	chan->max_antenna_gain = (int) MBI_TO_DBI(power_rule->max_antenna_gain);
 	chan->max_reg_power = chan->max_power =
 		(int) MBM_TO_DBM(power_rule->max_eirp);
-- 
1.9.1

Re: [PATCH] cfg80211: avoid intersection when applying custom reg

[Johannes Berg]

On Sun, 2014-12-07 at 18:03 +0200, Arik Nemtsov wrote:
> The custom-reg handling function can currently only add flags to a given
> channel. This results in stale flags being left applied. In some cases
> a channel was disabled and even the orig_flags were changed to reflect
> this.
> 
> Previously the API was designed for a single invocation before wiphy
> registration, so this didn't matter. The previous approach doesn't scale
> well to self-managed regulatory devices, particularly when a more
> permissive regdom is applied after a restrictive one.

This description (not the patch) only makes sense after the other series
with self-managed, please resend it in the self-managed patchset.

johannes

Re: [PATCH] cfg80211: avoid intersection when applying custom reg

[Arik Nemtsov]

On Fri, Dec 12, 2014 at 2:41 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
> On Sun, 2014-12-07 at 18:03 +0200, Arik Nemtsov wrote:
> > The custom-reg handling function can currently only add flags to a given
> > channel. This results in stale flags being left applied. In some cases
> > a channel was disabled and even the orig_flags were changed to reflect
> > this.
> >
> > Previously the API was designed for a single invocation before wiphy
> > registration, so this didn't matter. The previous approach doesn't scale
> > well to self-managed regulatory devices, particularly when a more
> > permissive regdom is applied after a restrictive one.
>
> This description (not the patch) only makes sense after the other series
> with self-managed, please resend it in the self-managed patchset.

Sure. I'll also make it self-managed only, so avoid possible
regressions, as Luis commented.

Arik

Re: [PATCH] cfg80211: avoid intersection when applying custom reg

[Luis R. Rodriguez]

On Sun, Dec 07, 2014 at 06:03:45PM +0200, Arik Nemtsov wrote:
> The custom-reg handling function can currently only add flags to a given
> channel. This results in stale flags being left applied. In some cases
> a channel was disabled and even the orig_flags were changed to reflect
> this.
> 
> Previously the API was designed for a single invocation before wiphy
> registration, so this didn't matter. The previous approach doesn't scale
> well to self-managed regulatory devices, particularly when a more
> permissive regdom is applied after a restrictive one.

So why not make this an excemption to only managed devices? You show the
issue but am not convinced this won't introduce regressions so would
prefer to make this an exception for managed devices.

  Luis