linux-stable.git/net/wireless, branch v3.5.2

cfg80211: process pending events when unregistering net device

2012-08-15T14:53:03+00:00

commit 1f6fc43e621167492ed4b7f3b4269c584c3d6ccc upstream.

libertas currently calls cfg80211_disconnected() when it is being
brought down. This causes an event to be allocated, but since the
wdev is already removed from the rdev by the time that the event
processing work executes, the event is never processed or freed.
http://article.gmane.org/gmane.linux.kernel.wireless.general/95666

Fix this leak, and other possible situations, by processing the event
queue when a device is being unregistered. Thanks to Johannes Berg for
the suggestion.

Signed-off-by: Daniel Drake 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

wireless: reg: restore previous behaviour of chan->max_power calculations

2012-08-15T14:52:47+00:00

commit 5e31fc0815a4e2c72b1b495fe7a0d8f9bfb9e4b4 upstream.

commit eccc068e8e84c8fe997115629925e0422a98e4de
Author: Hong Wu 
Date:   Wed Jan 11 20:33:39 2012 +0200

    wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit pow

changed the way we calculate chan->max_power as min(chan->max_power,
chan->max_reg_power). That broke rt2x00 (and perhaps some other
drivers) that do not set chan->max_power. It is not so easy to fix this
problem correctly in rt2x00.

According to commit eccc068e8 changelog, change claim only to save
maximum regulatory power - changing setting of chan->max_power was side
effect. This patch restore previous calculations of chan->max_power and
do not touch chan->max_reg_power.

Signed-off-by: Stanislaw Gruszka 
Acked-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

cfg80211: fix potential deadlock in regulatory

2012-06-13T08:17:53+00:00

reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.

reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.

Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.

This is the relevant lockdep warning:

cfg80211: Calling CRDA for country: XX

======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
 (cfg80211_mutex){+.+.+.}, at: [] restore_regulatory_settings+0x34/0x418 [cfg80211]

but task is already holding lock:
 ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 ((reg_timeout).work){+.+...}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] wait_on_work+0x4c/0x154
       [] __cancel_work_timer+0xd4/0x11c
       [] cancel_delayed_work_sync+0x1c/0x20
       [] reg_set_request_processed+0x50/0x78 [cfg80211]
       [] set_regdom+0x550/0x600 [cfg80211]
       [] nl80211_set_reg+0x218/0x258 [cfg80211]
       [] genl_rcv_msg+0x1a8/0x1e8
       [] netlink_rcv_skb+0x5c/0xc0
       [] genl_rcv+0x28/0x34
       [] netlink_unicast+0x15c/0x228
       [] netlink_sendmsg+0x218/0x298
       [] sock_sendmsg+0xa4/0xc0
       [] __sys_sendmsg+0x1e4/0x268
       [] sys_sendmsg+0x4c/0x70
       [] ret_fast_syscall+0x0/0x3c

-> #1 (reg_mutex){+.+.+.}:
       [] validate_chain+0xb94/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] reg_todo+0x30/0x538 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

-> #0 (cfg80211_mutex){+.+.+.}:
       [] print_circular_bug+0x68/0x2cc
       [] validate_chain+0x978/0x10f0
       [] __lock_acquire+0x8c8/0x9b0
       [] lock_acquire+0xf0/0x114
       [] mutex_lock_nested+0x48/0x320
       [] restore_regulatory_settings+0x34/0x418 [cfg80211]
       [] reg_timeout_work+0x1c/0x20 [cfg80211]
       [] process_one_work+0x2a0/0x480
       [] worker_thread+0x1bc/0x2bc
       [] kthread+0x98/0xa4
       [] kernel_thread_exit+0x0/0x8

other info that might help us debug this:

Chain exists of:
  cfg80211_mutex --> reg_mutex --> (reg_timeout).work

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((reg_timeout).work);
                               lock(reg_mutex);
                               lock((reg_timeout).work);
  lock(cfg80211_mutex);

 *** DEADLOCK ***

2 locks held by kworker/0:2/1391:
 #0:  (events){.+.+.+}, at: [] process_one_work+0x1f0/0x480
 #1:  ((reg_timeout).work){+.+...}, at: [] process_one_work+0x1f0/0x480

stack backtrace:
[] (unwind_backtrace+0x0/0x12c) from [] (dump_stack+0x20/0x24)
[] (dump_stack+0x20/0x24) from [] (print_circular_bug+0x280/0x2cc)
[] (print_circular_bug+0x280/0x2cc) from [] (validate_chain+0x978/0x10f0)
[] (validate_chain+0x978/0x10f0) from [] (__lock_acquire+0x8c8/0x9b0)
[] (__lock_acquire+0x8c8/0x9b0) from [] (lock_acquire+0xf0/0x114)
[] (lock_acquire+0xf0/0x114) from [] (mutex_lock_nested+0x48/0x320)
[] (mutex_lock_nested+0x48/0x320) from [] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [] (reg_timeout_work+0x1c/0x20 [cfg80211])
[] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [] (process_one_work+0x2a0/0x480)
[] (process_one_work+0x2a0/0x480) from [] (worker_thread+0x1bc/0x2bc)
[] (worker_thread+0x1bc/0x2bc) from [] (kthread+0x98/0xa4)
[] (kthread+0x98/0xa4) from [] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Cc: stable@kernel.org
Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg

cfg80211: check iface combinations only when iface is running

2012-06-09T08:31:56+00:00

Don't validate interface combinations on a stopped
interface. Otherwise we might end up being able to
create a new interface with a certain type, but
won't be able to change an existing interface
into that type.

This also skips some other functions when
interface is stopped and changing interface type.

Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg

cfg80211: fix interface combinations check

2012-06-05T18:27:30+00:00

If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.

Cc: stable@kernel.org
Reported-by: Mohammed Shafi Shajakhan 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: use sme_state in ibss start/join path

2012-06-04T19:21:28+00:00

CFG80211_DEV_WARN_ON() at "net/wireless/ibss.c line 63"
is unnecessarily triggered even after successful connection,
when cfg80211_ibss_joined() is called by driver inside
.join_ibss handler.

This patch fixes the problem by changing 'sme_state' in ibss path
and having WARN_ON() check for 'sme_state' similar to infra
association.

Signed-off-by: Amitkumar Karwar 
Signed-off-by: Bing Zhao 
Signed-off-by: John W. Linville

Merge git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next

2012-05-22T19:18:06+00:00

nl80211: refactor valid channel type check

2012-05-16T17:08:16+00:00

There are four instances in nl80211 of getting the
channel type from the attribute and validating it,
refactor those.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix cfg80211_can_beacon_sec_chan prototype

2012-05-16T17:08:15+00:00

It should return bool, not int. The function even
does return true/false.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

nl80211: prevent additions to old station flags API

2012-05-16T17:08:15+00:00

We don't really want/need to maintain the old
station flags API any more, so refuse changes
to new (not yet defined) flags from the old
flags API.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville