linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] mac80211: check whether scan is in progress before queueing scan_work
@ 2010-04-07  5:56 Teemu Paasikivi
  2010-04-07  6:29 ` Johannes Berg
  0 siblings, 1 reply; 2+ messages in thread
From: Teemu Paasikivi @ 2010-04-07  5:56 UTC (permalink / raw)
  To: linville; +Cc: linux-wireless, Teemu Paasikivi

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. This causes the stack to abort scan without notifying the driver
about it. This leads to a situation where the hw is scanning and the stack
thinks it's not. Then when the scan finishes, the stack will complain by
warnings.

Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
---
 net/mac80211/work.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index 1e1ea30..5df48a9 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -919,12 +919,17 @@ static void ieee80211_work_work(struct work_struct *work)
 		run_again(local, jiffies + HZ/2);
 	}
 
-	if (list_empty(&local->work_list) && local->scan_req)
+	mutex_unlock(&local->work_mtx);
+
+	mutex_lock(&local->scan_mtx);
+
+	if (list_empty(&local->work_list) && local->scan_req &&
+	    !local->scanning)
 		ieee80211_queue_delayed_work(&local->hw,
 					     &local->scan_work,
 					     round_jiffies_relative(0));
 
-	mutex_unlock(&local->work_mtx);
+	mutex_unlock(&local->scan_mtx);
 
 	ieee80211_recalc_idle(local);
 
-- 
1.5.6.3


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH v2] mac80211: check whether scan is in progress before queueing scan_work
  2010-04-07  5:56 [PATCH v2] mac80211: check whether scan is in progress before queueing scan_work Teemu Paasikivi
@ 2010-04-07  6:29 ` Johannes Berg
  0 siblings, 0 replies; 2+ messages in thread
From: Johannes Berg @ 2010-04-07  6:29 UTC (permalink / raw)
  To: Teemu Paasikivi; +Cc: linville, linux-wireless

On Wed, 2010-04-07 at 08:56 +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. This causes the stack to abort scan without notifying the driver
> about it. This leads to a situation where the hw is scanning and the stack
> thinks it's not. Then when the scan finishes, the stack will complain by
> warnings.
> 
> Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
> ---
>  net/mac80211/work.c |    9 +++++++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/net/mac80211/work.c b/net/mac80211/work.c
> index 1e1ea30..5df48a9 100644
> --- a/net/mac80211/work.c
> +++ b/net/mac80211/work.c
> @@ -919,12 +919,17 @@ static void ieee80211_work_work(struct work_struct *work)
>  		run_again(local, jiffies + HZ/2);
>  	}
>  
> -	if (list_empty(&local->work_list) && local->scan_req)
> +	mutex_unlock(&local->work_mtx);
> +
> +	mutex_lock(&local->scan_mtx);
> +
> +	if (list_empty(&local->work_list) && local->scan_req &&
> +	    !local->scanning)
>  		ieee80211_queue_delayed_work(&local->hw,
>  					     &local->scan_work,
>  					     round_jiffies_relative(0));
>  
> -	mutex_unlock(&local->work_mtx);
> +	mutex_unlock(&local->scan_mtx);

But should we touch work_list w/o holding work_mtx?

johannes


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-04-07  6:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-07  5:56 [PATCH v2] mac80211: check whether scan is in progress before queueing scan_work Teemu Paasikivi
2010-04-07  6:29 ` Johannes Berg

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).