linux-toradex.git/net/wireless/wext-compat.c, branch v3.0.3

Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

2011-03-04T05:27:42+00:00

Conflicts:
	drivers/net/bnx2x/bnx2x.h

fix cfg80211_wext_siwfreq lock ordering...

2011-02-21T20:14:25+00:00

I previously managed to reproduce a hang while scanning wireless
channels (reproducible with airodump-ng hopping channels); subsequent
lockdep instrumentation revealed a lock ordering issue.

Without knowing the design intent, it looks like the locks should be
taken in reverse order; please comment.

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.38-rc5-341cd #4
-------------------------------------------------------
airodump-ng/15445 is trying to acquire lock:
 (&rdev->devlist_mtx){+.+.+.}, at: []
cfg80211_wext_siwfreq+0xc6/0x100

but task is already holding lock:
 (&wdev->mtx){+.+.+.}, at: [] cfg80211_wext_siwfreq+0xbc/0x100

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&wdev->mtx){+.+.+.}:
       [] lock_acquire+0xc6/0x280
       [] mutex_lock_nested+0x6e/0x4b0
       [] cfg80211_netdev_notifier_call+0x430/0x5f0
       [] notifier_call_chain+0x8b/0x100
       [] raw_notifier_call_chain+0x11/0x20
       [] call_netdevice_notifiers+0x32/0x60
       [] __dev_notify_flags+0x34/0x80
       [] dev_change_flags+0x40/0x70
       [] do_setlink+0x1fc/0x8d0
       [] rtnl_setlink+0xf2/0x140
       [] rtnetlink_rcv_msg+0x163/0x270
       [] netlink_rcv_skb+0xa1/0xd0
       [] rtnetlink_rcv+0x20/0x30
       [] netlink_unicast+0x2ba/0x300
       [] netlink_sendmsg+0x267/0x3e0
       [] sock_sendmsg+0xe4/0x110
       [] sys_sendmsg+0x253/0x3b0
       [] system_call_fastpath+0x16/0x1b

-> #0 (&rdev->devlist_mtx){+.+.+.}:
       [] __lock_acquire+0x1622/0x1d10
       [] lock_acquire+0xc6/0x280
       [] mutex_lock_nested+0x6e/0x4b0
       [] cfg80211_wext_siwfreq+0xc6/0x100
       [] ioctl_standard_call+0x5d/0xd0
       [] T.808+0x163/0x170
       [] wext_handle_ioctl+0x3a/0x90
       [] dev_ioctl+0x6f2/0x830
       [] sock_ioctl+0xfd/0x290
       [] do_vfs_ioctl+0x9d/0x590
       [] sys_ioctl+0x4a/0x80
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

2 locks held by airodump-ng/15445:
 #0:  (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
 #1:  (&wdev->mtx){+.+.+.}, at: []
cfg80211_wext_siwfreq+0xbc/0x100

stack backtrace:
Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
Call Trace:
 [] ? print_circular_bug+0xfa/0x100
 [] ? __lock_acquire+0x1622/0x1d10
 [] ? trace_hardirqs_off_caller+0x29/0xc0
 [] ? lock_acquire+0xc6/0x280
 [] ? cfg80211_wext_siwfreq+0xc6/0x100
 [] ? mark_held_locks+0x67/0x90
 [] ? mutex_lock_nested+0x6e/0x4b0
 [] ? cfg80211_wext_siwfreq+0xc6/0x100
 [] ? mark_held_locks+0x67/0x90
 [] ? cfg80211_wext_siwfreq+0xc6/0x100
 [] ? cfg80211_wext_siwfreq+0xc6/0x100
 [] ? ioctl_standard_call+0x5d/0xd0
 [] ? __dev_get_by_name+0x9b/0xc0
 [] ? ioctl_standard_call+0x0/0xd0
 [] ? T.808+0x163/0x170
 [] ? might_fault+0x72/0xd0
 [] ? wext_handle_ioctl+0x3a/0x90
 [] ? might_fault+0xbb/0xd0
 [] ? dev_ioctl+0x6f2/0x830
 [] ? put_lock_stats+0xe/0x40
 [] ? lock_release_holdtime+0xac/0x150
 [] ? sock_ioctl+0xfd/0x290
 [] ? do_vfs_ioctl+0x9d/0x590
 [] ? fget_light+0x1df/0x3c0
 [] ? sys_ioctl+0x4a/0x80
 [] ? system_call_fastpath+0x16/0x1b

Signed-off-by: Daniel J Blueman 
Acked-by: Johannes Berg 
Signed-off-by: John W. Linville

cfg80211: Extend channel to frequency mapping for 802.11j

2011-01-21T20:34:17+00:00

Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.

This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.

The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.

Signed-off-by: Bruno Randolf 
Signed-off-by: Brian Prodoehl 
Acked-by: Luciano Coelho 
Signed-off-by: John W. Linville

cfg80211/nl80211: separate unicast/multicast default TX keys

2010-12-13T20:23:28+00:00

Allow userspace to specify that a given key
is default only for unicast and/or multicast
transmissions. Only WEP keys are for both,
WPA/RSN keys set here are GTKs for multicast
only. For more future flexibility, allow to
specify all combiations.

Wireless extensions can only set both so use
nl80211; WEP keys (connect keys) must be set
as default for both (but 802.1X WEP is still
possible).

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

wireless: Set some stats used by /proc/net/wireless (wext)

2010-10-11T19:04:19+00:00

Some stats for /proc/net/wireless (and wext in general) are not
being set.  This patch addresses a few of those with values easily
obtained from mac80211 core.

Signed-off-by: Ben Greear 
Signed-off-by: John W. Linville

cfg80211/mac80211: allow per-station GTKs

2010-10-06T20:30:40+00:00

This adds API to allow adding per-station GTKs,
updates mac80211 to support it, and also allows
drivers to remove a key from hwaccel again when
this may be necessary due to multiple GTKs.

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

wireless extensions: fix kernel heap content leak

2010-08-30T20:35:17+00:00

Wireless extensions have an unfortunate, undocumented
requirement which requires drivers to always fill
iwp->length when returning a successful status. When
a driver doesn't do this, it leads to a kernel heap
content leak when userspace offers a larger buffer
than would have been necessary.

Arguably, this is a driver bug, as it should, if it
returns 0, fill iwp->length, even if it separately
indicated that the buffer contents was not valid.

However, we can also at least avoid the memory content
leak if the driver doesn't do this by setting the iwp
length to max_tokens, which then reflects how big the
buffer is that the driver may fill, regardless of how
big the userspace buffer is.

To illustrate the point, this patch also fixes a
corresponding cfg80211 bug (since this requirement
isn't documented nor was ever pointed out by anyone
during code review, I don't trust all drivers nor
all cfg80211 handlers to implement it correctly).

Cc: stable@kernel.org [all the way back]
Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville

wireless: correct sparse warning in wext-compat.c

2010-07-20T20:49:37+00:00

  CHECK   net/wireless/wext-compat.c
net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?

Add declaration in cfg80211.h.  Also add an EXPORT_SYMBOL_GPL, since all
the peer functions have it.

Signed-off-by: John W. Linville

cfg80211/mac80211: Update set_tx_power to use mBm instead of dBm units

2010-06-24T19:42:33+00:00

In preparation for a TX power setting interface in the nl80211, change the
.set_tx_power function to use mBm units instead of dBm for greater accuracy and
smaller power levels.

Also, already in advance move the tx_power_setting enumeration to nl80211.

This change affects the .tx_set_power function prototype. As a result, the
corresponding changes are needed to modules using it. These are mac80211,
iwmc3200wifi and rndis_wlan.

Cc: Samuel Ortiz 
Cc: Jussi Kivilinna 
Signed-off-by: Juuso Oikarinen 
Acked-by: Samuel Ortiz 
Acked-by: Jussi Kivilinna 
Signed-off-by: John W. Linville

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

2010-05-11T18:24:55+00:00

Conflicts:
	drivers/net/wireless/ath/ar9170/main.c