kernel.git/net/wireless/wext-compat.c, branch linux-2.6.37.y

fix cfg80211_wext_siwfreq lock ordering...

2011-03-07T23:05:22Z

commit 4f919a3bc54da01db829c520ce4b1fabfde1c3f7 upstream. 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 Signed-off-by: Greg Kroah-Hartman

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

2010-10-11T19:04:19Z

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:40Z

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:17Z

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:37Z

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:33Z

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:55Z

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

cfg80211/mac80211: better channel handling

2010-05-07T18:55:50Z

Currently (all tested with hwsim) you can do stupid things like setting up an AP on a certain channel, then adding another virtual interface and making that associate on another channel -- this will make the beaconing to move channel but obviously without the necessary IEs data update. In order to improve this situation, first make the configuration APIs (cfg80211 and nl80211) aware of multi-channel operation -- we'll eventually need that in the future anyway. There's one userland API change and one API addition. The API change is that now SET_WIPHY must be called with virtual interface index rather than only wiphy index in order to take effect for that interface -- luckily all current users (hostapd) do that. For monitor interfaces, the old setting is preserved, but monitors are always slaved to other devices anyway so no guarantees. The second userland API change is the introduction of a per virtual interface SET_CHANNEL command, that hostapd should use going forward to make it easier to understand what's going on (it can automatically detect a kernel with this command). Other than mac80211, no existing cfg80211 drivers are affected by this change because they only allow a single virtual interface. mac80211, however, now needs to be aware that the channel settings are per interface now, and needs to disallow (for now) real multi-channel operation, which is another important part of this patch. One of the immediate benefits is that you can now start hostapd to operate on a hardware that already has a connection on another virtual interface, as long as you specify the same channel. Note that two things are left unhandled (this is an improvement -- not a complete fix): * different HT/no-HT modes currently you could start an HT AP and then connect to a non-HT network on the same channel which would configure the hardware for no HT; that can be fixed fairly easily * CSA An AP we're connected to on a virtual interface might indicate switching channels, and in that case we would follow it, regardless of how many other interfaces are operating; this requires more effort to fix but is pretty rare after all Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32Z

percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo Guess-its-ok-by: Christoph Lameter Cc: Ingo Molnar Cc: Lee Schermerhorn

nl80211: add power save commands

2010-02-19T20:52:40Z

The most needed command from nl80211, which Wireless Extensions had, is support for power save mode. Add a simple command to make it possible to enable and disable power save via nl80211. I was also planning about extending the interface, for example adding the timeout value, but after thinking more about this I decided not to do it. Basically there were three reasons: Firstly, the parameters for power save are very much hardware dependent. Trying to find a unified interface which would work with all hardware, and still make sense to users, will be very difficult. Secondly, IEEE 802.11 power save implementation in Linux is still in state of flux. We have a long way to still to go and there is no way to predict what kind of implementation we will have after few years. And because we need to support nl80211 interface a long time, practically forever, adding now parameters to nl80211 might create maintenance problems later on. Third issue are the users. Power save parameters are mostly used for debugging, so debugfs is better, more flexible, interface for this. For example, wpa_supplicant currently doesn't configure anything related to power save mode. It's better to strive that kernel can automatically optimise the power save parameters, like with help of pm qos network and other traffic parameters. Later on, when we have better understanding of power save, we can extend this command with more features, if there's a need for that. Signed-off-by: Kalle Valo Signed-off-by: John W. Linville