From: Dan Williams <dcbw@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>,
"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 11:07:39 -0700 [thread overview]
Message-ID: <1270577259.8534.17.camel@localhost.localdomain> (raw)
In-Reply-To: <1270574265.24505.3.camel@jlt3.sipsolutions.net>
On Tue, 2010-04-06 at 19:17 +0200, Johannes Berg wrote:
> On Tue, 2010-04-06 at 09:23 -0700, Dan Williams wrote:
>
> > > Yes, I'm bit worried about possibility of a possible deadlock too. One
> > > solution would be to move the block acquiring scan_mtx and queueing
> > > scan_work outside of the work_mtx locked section, I'll take a look on
> > > that. In any case, this patch won't most likely fix all issues with the
> > > locking here. For example there's that checking if scan is in progress
> > > in the beginning of the work_work. After that it is still possible that
> > > the scan is started. So there's obviously need for some fixing in the
> > > locking yet to be done.
> >
> > One issue would be if the new scan request has different parameters than
> > the in-progress scan request. This is especially important when the
> > incoming scan request is for a specific SSID (hidden network probing)
> > while the ongoing one is not. Can we make sure that the patch at least
> > returns the error up the stack when the incoming scan is dropped?
> > Otherwise userspace has no idea that the specific SSID scan was dropped
> > on the floor, and just thinks that the hidden SSID wasn't found.
>
> There's no scan request being dropped -- it's just that we try to ask
> the hw to do the same scan twice without noticing that we've already
> asked it.
Aha; thanks for the clarification.
Dan
next prev parent reply other threads:[~2010-04-06 18:07 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
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 [this message]
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=1270577259.8534.17.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=ext-teemu.3.paasikivi@nokia.com \
--cc=johannes@sipsolutions.net \
--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.