linux-toradex.git/net/wireless, branch v3.2.24

cfg80211: check iface combinations only when iface is running

2012-07-25T03:11:20+00:00

commit f8cdddb8d61d16a156229f0910f7ecfc7a82c003 upstream.

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 
Signed-off-by: Ben Hutchings

cfg80211: fix potential deadlock in regulatory

2012-07-04T04:44:18+00:00

commit fe20b39ec32e975f1054c0b7866c873a954adf05 upstream.

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)

Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Ben Hutchings

cfg80211: fix interface combinations check

2012-06-19T22:18:14+00:00

commit 463454b5dbd8dbab6e2fc6c557329e5b811b9c32 upstream.

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.

Reported-by: Mohammed Shafi Shajakhan 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB

2012-05-30T23:43:22+00:00

commit 80007efeff0568375b08faf93c7aad65602cb97e upstream.

It has happened twice now where elaborate troubleshooting has
undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
has been set but yet net/wireless/db.txt was not updated.

Despite the documentation on this it seems system integrators could
use some more help with this, so throw out a kernel warning at boot time
when their database is empty.

This does mean that the error-prone system integrator won't likely
realize the issue until they boot the machine but -- it does not seem
to make sense to enable a build bug breaking random build testing.

[0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB

Cc: Stephen Rothwell 
Cc: Youngsin Lee 
Cc: Raja Mani 
Cc: Senthil Kumar Balasubramanian 
Cc: Vipin Mehta 
Cc: yahuan@qca.qualcomm.com
Cc: jjan@qca.qualcomm.com
Cc: vthiagar@qca.qualcomm.com
Cc: henrykim@qualcomm.com
Cc: jouni@qca.qualcomm.com
Cc: athiruve@qca.qualcomm.com
Cc: cjkim@qualcomm.com
Cc: philipk@qca.qualcomm.com
Cc: sunnykim@qualcomm.com
Cc: sskwak@qualcomm.com
Cc: kkim@qualcomm.com
Cc: mattbyun@qualcomm.com
Cc: ryanlee@qualcomm.com
Cc: simbap@qualcomm.com
Cc: krislee@qualcomm.com
Cc: conner@qualcomm.com
Cc: hojinkim@qualcomm.com
Cc: honglee@qualcomm.com
Cc: johnwkim@qualcomm.com
Cc: jinyong@qca.qualcomm.com
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

nl80211: ensure interface is up in various APIs

2012-05-11T12:14:40+00:00

commit 2b5f8b0b44e17e625cfba1e7b88db44f4dcc0441 upstream.
[backported by Ben Greear]

The nl80211 handling code should ensure as much as
it can that the interface is in a valid state, it
can certainly ensure the interface is running.

Not doing so can cause calls through mac80211 into
the driver that result in warnings and unspecified
behaviour in the driver.

Reported-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Greear 
Signed-off-by: Ben Hutchings

cfg80211: fix interface combinations check.

2012-05-11T12:13:58+00:00

commit e55a4046dab28c440c96890bdddcf02dc8981f2d upstream.

Signed-off-by: Lukasz Kucharczyk 
Signed-off-by: John W. Linville 
Signed-off-by: Ben Hutchings

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

2011-12-05T16:05:44+00:00

cfg80211: amend regulatory NULL dereference fix

2011-11-30T19:16:33+00:00

Johannes' patch for "cfg80211: fix regulatory NULL dereference"
broke user regulaotry hints and it did not address the fact that
last_request was left populated even if the previous regulatory
hint was stale due to the wiphy disappearing.

Fix user reguluatory hints by only bailing out if for those
regulatory hints where a request_wiphy is expected. The stale last_request
considerations are addressed through the previous fixes on last_request
where we reset the last_request to a static world regdom request upon
reset_regdomains(). In this case though we further enhance the effect
by simply restoring reguluatory settings completely.

Cc: stable@vger.kernel.org
Cc: Johannes Berg 
Signed-off-by: Luis R. Rodriguez 
Reviewed-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: fix race on init and driver registration

2011-11-30T19:16:31+00:00

There is a theoretical race that if hit will trigger
a crash. The race is between when we issue the first
regulatory hint, regulatory_hint_core(), gets processed
by the workqueue and between when the first device
gets registered to the wireless core. This is not easy
to reproduce but it was easy to do so through the
regulatory simulator I have been working on. This
is a port of the fix I implemented there [1].

[1] https://github.com/mcgrof/regsim/commit/a246ccf81f059cb662eee288aa13100f631e4cc8

Cc: stable@vger.kernel.org
Cc: Johannes Berg 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: John W. Linville

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem

2011-11-30T19:14:42+00:00