diff mbox

[1/5] nl80211: fix validation of scheduled scan info for wowlan netdetect

Message ID 1485518971-28183-2-git-send-email-arend.vanspriel@broadcom.com (mailing list archive)
State Superseded
Headers show

Commit Message

Arend van Spriel Jan. 27, 2017, 12:09 p.m. UTC 
For wowlan netdetect a separate limit is defined for the number of
matchsets. Currently, this limit is ignored and the regular limit
for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
used for the net-detect case as well.

Cc: Johannes Berg <johannes@sipsolutions.net>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
 net/wireless/nl80211.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--
1.9.1

Comments

Johannes Berg Jan. 27, 2017, 12:31 p.m. UTC | #1 
On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.
> 

But .. this patch shouldn't be first in the series, should it? That
leaves brcmfmac broken inbetween.

Also, since you fix the brcmfmac value in patch 2, and it's the same in
both cases, I don't really see a dependency of anything *on* the
nl80211 patch? The brcmfmac changes can go in without it entirely, and
have no effect whatsoever, no?

IOW, I think Kalle can merge 2-5, and I can then pick up this one when
they hit net-next and I've synchronized, no?

johannes
Arend van Spriel Jan. 27, 2017, 12:38 p.m. UTC | #2 
On 27-1-2017 13:31, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
>>
> 
> But .. this patch shouldn't be first in the series, should it? That
> leaves brcmfmac broken inbetween.
> 
> Also, since you fix the brcmfmac value in patch 2, and it's the same in
> both cases, I don't really see a dependency of anything *on* the
> nl80211 patch? The brcmfmac changes can go in without it entirely, and
> have no effect whatsoever, no?

Patch 4 depends on patch 2. Patch 1 and 2 were a single patch, but I
decided to separate them. So yeah, now patch 1 actually depends on patch
2 in order not to break brcmfmac.

> IOW, I think Kalle can merge 2-5, and I can then pick up this one when
> they hit net-next and I've synchronized, no?

Agree.

Regards,
Arend
Johannes Berg Jan. 27, 2017, 12:42 p.m. UTC | #3 
On Fri, 2017-01-27 at 13:38 +0100, Arend Van Spriel wrote:
> 
> > IOW, I think Kalle can merge 2-5, and I can then pick up this one
> > when they hit net-next and I've synchronized, no?
> 
> Agree.

Alright. I see you submitted another version, I'll assign 2-5 to Kalle,
and keep 1 for myself, and not worry about the ordering since I'm the
one to have to remember to actually apply it later :)

johannes
Johannes Berg Feb. 8, 2017, 9:10 a.m. UTC | #4 
On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
> For wowlan netdetect a separate limit is defined for the number of
> matchsets. Currently, this limit is ignored and the regular limit
> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
> used for the net-detect case as well.

Applied.

This means that brmcfmac is now broken in mac80211-next for a bit, but
once it hits net-next and I merge back everything will be fine again,
so just a few days (and I assume nobody us using brcmfmac from
mac80211-next anyway ... wireless-testing will be fine)

johannes
Arend van Spriel Feb. 8, 2017, 9:56 a.m. UTC | #5 
On 8-2-2017 10:10, Johannes Berg wrote:
> On Fri, 2017-01-27 at 12:09 +0000, Arend van Spriel wrote:
>> For wowlan netdetect a separate limit is defined for the number of
>> matchsets. Currently, this limit is ignored and the regular limit
>> for scheduled scan matchsets, ie. struct wiphy::max_match_sets, is
>> used for the net-detect case as well.
> 
> Applied.
> 
> This means that brmcfmac is now broken in mac80211-next for a bit, but
> once it hits net-next and I merge back everything will be fine again,
> so just a few days (and I assume nobody us using brcmfmac from
> mac80211-next anyway ... wireless-testing will be fine)

Well. Almost nobody :-p

Gr. AvS
diff mbox

Patch

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93..90833a4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6850,7 +6850,7 @@  static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)

 static struct cfg80211_sched_scan_request *
 nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
-			 struct nlattr **attrs)
+			 struct nlattr **attrs, int max_match_sets)
 {
 	struct cfg80211_sched_scan_request *request;
 	struct nlattr *attr;
@@ -6915,7 +6915,7 @@  static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
 	if (!n_match_sets && default_match_rssi != NL80211_SCAN_RSSI_THOLD_OFF)
 		n_match_sets = 1;

-	if (n_match_sets > wiphy->max_match_sets)
+	if (n_match_sets > max_match_sets)
 		return ERR_PTR(-EINVAL);

 	if (attrs[NL80211_ATTR_IE])
@@ -7189,7 +7189,8 @@  static int nl80211_start_sched_scan(struct sk_buff *skb,
 		return -EINPROGRESS;

 	sched_scan_req = nl80211_parse_sched_scan(&rdev->wiphy, wdev,
-						  info->attrs);
+						  info->attrs,
+						  rdev->wiphy.max_match_sets);

 	err = PTR_ERR_OR_ZERO(sched_scan_req);
 	if (err)
@@ -9966,7 +9967,8 @@  static int nl80211_parse_wowlan_nd(struct cfg80211_registered_device *rdev,
 	if (err)
 		goto out;

-	trig->nd_config = nl80211_parse_sched_scan(&rdev->wiphy, NULL, tb);
+	trig->nd_config = nl80211_parse_sched_scan(&rdev->wiphy, NULL, tb,
+						   wowlan->max_nd_match_sets);
 	err = PTR_ERR_OR_ZERO(trig->nd_config);
 	if (err)
 		trig->nd_config = NULL;