From: Johannes Berg <johannes@sipsolutions.net>
To: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
Cc: "linville@tuxdriver.com" <linville@tuxdriver.com>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH] mac80211: check whether scan is in progress before queueing scan_work
Date: Tue, 06 Apr 2010 12:27:57 +0200 [thread overview]
Message-ID: <1270549677.3929.5.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1270549017.7150.28.camel@paavo-desktop>
On Tue, 2010-04-06 at 13:16 +0300, Teemu Paasikivi wrote:
> On Tue, 2010-04-06 at 11:06 +0200, ext Johannes Berg wrote:
> > On Tue, 2010-04-06 at 11:54 +0300, Teemu Paasikivi wrote:
> > > As scan_work is queued from work_work it needs to be checked if scan
> > > has been started during execution of work_work. Otherwise, when hw
> > > scan is used, the stack gets error about hw being busy with ongoing
> > > scan.
> >
> > Does that mean we ask the driver to scan twice? And your particular
> > driver returns busy?
> >
>
> Yes. There seems to be a possibility, that when ieee80211_work_work is
> being executed, __ieee80211_start_scan gets called and it starts a hw
> scan, and also sets local->hw_scan_req etc. (because it looks like
> there's some holes in use of scan_mtx). Result is that work_work queues
> ieee80211_scan_work and when it is executed, as there's already
> hw_scan_req set, it will try to start hw scan again. And as the driver
> used returns busy, scan_work will call ieee80211_scan_completed function
> which leaves the driver (hw more precisely) scanning and the stack
> thinking that it is not anymore scanning.
>
> Obviously this kind of situation doesn't happen very often in normal
> use, but it can be caused quite easily by associating to access points
> in a loop while running scan in another loop.
Makes some sense. Ignore my other email(s), I looked at this in more
detail now.
It would appear that we need to fix some of the locking here,
potentially simply using a single mutex for both work and scan?
johannes
next prev parent reply other threads:[~2010-04-06 10:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 8:54 [PATCH] mac80211: check whether scan is in progress before queueing scan_work Teemu Paasikivi
2010-04-06 9:06 ` Johannes Berg
2010-04-06 9:08 ` Johannes Berg
2010-04-06 10:16 ` Teemu Paasikivi
2010-04-06 10:27 ` Johannes Berg [this message]
2010-04-06 10:29 ` Johannes Berg
2010-04-06 11:05 ` Teemu Paasikivi
2010-04-06 16:23 ` Dan Williams
2010-04-06 17:17 ` Johannes Berg
2010-04-06 18:07 ` Dan Williams
2010-04-07 6:09 ` Teemu Paasikivi
2010-04-09 8:09 ` Johannes Berg
-- strict thread matches above, loose matches on Subject: below --
2010-04-09 10:07 Teemu Paasikivi
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=1270549677.3929.5.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ext-teemu.3.paasikivi@nokia.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.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.