From: Johannes Berg <johannes@sipsolutions.net>
To: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH V3 4/9] cfg80211: add request id to cfg80211_sched_scan_*() api
Date: Wed, 26 Apr 2017 09:16:34 +0200 [thread overview]
Message-ID: <1493190994.2464.3.camel@sipsolutions.net> (raw)
In-Reply-To: <1492776308-15120-5-git-send-email-arend.vanspriel@broadcom.com>
On Fri, 2017-04-21 at 13:05 +0100, Arend van Spriel wrote:
> Have proper request id filled in the SCHED_SCAN_RESULTS and
> SCHED_SCAN_STOPPED notifications toward user-space by having the
> driver provide it through the api.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.co
> m>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
All your reviewers aren't paying attention ;-)
> @@ -1722,6 +1723,7 @@ struct cfg80211_sched_scan_request {
> struct cfg80211_bss_select_adjust rssi_adjust;
>
> /* internal */
> + struct work_struct results_wk;
> struct wiphy *wiphy;
> struct net_device *dev;
> unsigned long scan_start;
Superficially, this is fine - but you need to think hard about the
semantics of when you cancel this work.
> +++ b/net/wireless/scan.c
> @@ -369,15 +369,13 @@ void __cfg80211_sched_scan_results(struct
> work_struct *wk)
> struct cfg80211_registered_device *rdev;
> struct cfg80211_sched_scan_request *request;
>
> - rdev = container_of(wk, struct cfg80211_registered_device,
> - sched_scan_results_wk);
> + request = container_of(wk, struct
> cfg80211_sched_scan_request, results_wk);
> + rdev = wiphy_to_rdev(request->wiphy);
>
> rtnl_lock();
>
> - request = cfg80211_find_sched_scan_req(rdev, 0);
> -
> /* we don't have sched_scan_req anymore if the scan is
> stopping */
That comment is kinda wrong now, afaict? Also you return
> - if (!IS_ERR(request)) {
> + if (request) {
This seems wrong - you do return an ERR_PTR() from find. Not that
there's all that much point in doing so vs. returning NULL, might be
worth cleaning it up.
> -void cfg80211_sched_scan_results(struct wiphy *wiphy)
> +void cfg80211_sched_scan_results(struct wiphy *wiphy, u64 reqid)
> {
> - struct cfg80211_registered_device *rdev =
> wiphy_to_rdev(wiphy);
> struct cfg80211_sched_scan_request *request;
>
> - trace_cfg80211_sched_scan_results(wiphy);
> + trace_cfg80211_sched_scan_results(wiphy, reqid);
> /* ignore if we're not scanning */
>
> rtnl_lock();
> - request = cfg80211_find_sched_scan_req(rdev, 0);
> + request = cfg80211_find_sched_scan_req(wiphy_to_rdev(wiphy),
> reqid);
> rtnl_unlock();
>
> if (!IS_ERR(request))
> - queue_work(cfg80211_wq,
> - &wiphy_to_rdev(wiphy)-
> >sched_scan_results_wk);
> + queue_work(cfg80211_wq, &request->results_wk);
> + else
> + wiphy_err(wiphy, "reqid %llu not found\n", reqid);
> }
This seems problematic - you use the request pointer outside the
locking now. I'd move that rtnl_unlock() to afterwards. The message
could also mention sched scan, that might be useful. Although I suspect
that may happen due to races (e.g. netlink socket close vs. firmware
stop) so maybe it's not all that useful.
Most importantly though, you don't protect against queuing the work
here, and then deleting the request. In the old case the comment that I
pointed out above will save us, but in this new case it can't (the
comment is now wrong), and that's a problem.
I looked briefly at this and I suspect it will be very hard to fix that
with a per-request work struct. It might be better to have a per-work
status flag that you set here, then you schedule the global work, and
that global work will send all the appropriate result messages after
clearing the status bit again, similar to what I did with the netlink
destroy now.
johannes
next prev parent reply other threads:[~2017-04-26 7:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 12:04 [PATCH V3 0/9] cfg80211: support multiple scheduled scans Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 1/9] nl80211: allow multiple active scheduled scan requests Arend van Spriel
2017-04-25 19:49 ` Johannes Berg
2017-04-26 6:50 ` Johannes Berg
2017-04-26 8:46 ` Arend van Spriel
2017-04-26 8:49 ` Johannes Berg
2017-04-26 9:05 ` Arend van Spriel
2017-04-26 9:08 ` Johannes Berg
2017-04-26 10:24 ` Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 2/9] nl80211: add support for BSSIDs in scheduled scan matchsets Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 3/9] cfg80211: add request id parameter to .sched_scan_stop() signature Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 4/9] cfg80211: add request id to cfg80211_sched_scan_*() api Arend van Spriel
2017-04-26 7:16 ` Johannes Berg [this message]
2017-04-26 18:18 ` Arend Van Spriel
2017-04-26 18:47 ` Johannes Berg
2017-04-21 12:05 ` [PATCH V3 5/9] brcmfmac: add firmware feature detection for gscan feature Arend van Spriel
2017-05-18 13:36 ` [V3, " Kalle Valo
2017-05-18 15:47 ` Kalle Valo
2017-05-18 19:34 ` Arend Van Spriel
2017-05-19 5:03 ` Kalle Valo
2017-04-21 12:05 ` [PATCH V3 6/9] brcmfmac: move scheduled scan wiphy param setting to pno module Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 7/9] brcmfmac: add support multi-scheduled scan Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 8/9] brcmfmac: add mutex to protect pno requests Arend van Spriel
2017-04-21 12:05 ` [PATCH V3 9/9] brcmfmac: add scheduled scan support for specified BSSIDs Arend van Spriel
2017-04-26 7:07 ` [PATCH V3 0/9] cfg80211: support multiple scheduled scans Johannes Berg
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=1493190994.2464.3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=arend.vanspriel@broadcom.com \
--cc=linux-wireless@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).