kernel.git/net/mac80211/offchannel.c, branch linux-3.8.y

mac80211: fix remain-on-channel cancel crash

2013-04-12T16:52:07Z

commit 3fbd45ca8d1c98f3c2582ef8bc70ade42f70947b upstream. If a ROC item is canceled just as it expires, the work struct may be scheduled while it is running (and waiting for the mutex). This results in it being run after being freed, which obviously crashes. To fix this don't free it when aborting is requested but instead mark it as "to be freed", which makes the work a no-op and allows freeing it outside. Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: synchronize scan off/on-channel and PS states

2013-01-16T14:06:18Z

Since: commit b23b025fe246f3acc2988eb6d400df34c27cb8ae Author: Ben Greear Date: Fri Feb 4 11:54:17 2011 -0800 mac80211: Optimize scans on current operating channel. we do not disable PS while going back to operational channel (on ieee80211_scan_state_suspend) and deffer that until scan finish. But since we are allowed to send frames, we can send a frame to AP without PM bit set, so disable PS on AP side. Then when we switch to off-channel (in ieee80211_scan_state_resume) we do not enable PS. Hence we are off-channel with PS disabled, frames are not buffered by AP. To fix remove offchannel_ps_disable argument and always enable PS when going off-channel and disable it when going on-channel, like it was before. Cc: stable@vger.kernel.org # 2.6.39+ Signed-off-by: Stanislaw Gruszka Tested-by: Seth Forshee Signed-off-by: Johannes Berg

Merge tag 'nfc-fixes-3.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-3.0

2012-12-06T19:55:57Z

This is an NFC LLCP fix for 3.7 and contains only one patch. It fixes a potential crash when receiving an LLCP HDLC frame acking a frame that is not the last sent one. In that case we may dereference an already freed pointer.

mac80211: fix remain-on-channel (non-)cancelling

2012-11-26T19:41:40Z

Felix Liao reported that when an interface is set DOWN while another interface is executing a ROC, the warning in ieee80211_start_next_roc() (about the first item on the list having started already) triggers. This is because ieee80211_roc_purge() calls it even if it never actually changed the list of ROC items. To fix this, simply remove the function call. If it is needed then it will be done by the ieee80211_sw_roc_work() function when the ROC item that is being removed while active is cleaned up. Cc: stable@vger.kernel.org Reported-by: Felix Liao Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

cfg80211: remove remain-on-channel channel type

2012-11-26T11:42:58Z

As mwifiex (and mac80211 in the software case) are the only drivers actually implementing remain-on-channel with channel type, userspace can't be relying on it. This is the case, as it's used only for P2P operations right now. Rather than adding a flag to tell userspace whether or not it can actually rely on it, simplify all the code by removing the ability to use different channel types. Leave only the validation of the attribute, so that if we extend it again later (with the needed capability flag), it can't break userspace sending invalid data. Signed-off-by: Johannes Berg

mac80211: make remain_on_channel() op pass vif param

2012-11-19T15:20:37Z

Drivers (e.g. wl12xx) might need to know the vif to roc on (mainly in order to configure the rx filters correctly). Add the vif to the op params, and update the current users (iwlwifi) to use the new api. Signed-off-by: Eliad Peller [fix hwsim] Signed-off-by: Johannes Berg

mac80211: use a counter for remain-on-channel cookie

2012-10-30T08:33:40Z

Instead of using the pointer which can be re-used fairly quickly due to allocator patterns and then makes debugging difficult, maintain a counter and use its value. Since it's a 64-bit value it can't really wrap, but catch that case anyway since it most likely points to a bug somewhere. Signed-off-by: Johannes Berg

mac80211: use channel contexts

2012-10-17T09:02:09Z

Instead of operating on a single channel only, use the new channel context infrastructure in all mac80211 code. This enables drivers that want to use the new channel context infrastructure to use multiple channels, while nothing should change for all the other drivers that don't support it. Right now this disables both TX power settings and spatial multiplexing powersave. Both need to be re-enabled on a channel context basis. Additionally, when channel contexts are used drop the connection when channel switch is received rather than trying to handle it. This will have to be improved later. [With fixes from Eliad and Emmanuel incorporated] Signed-off-by: Eliad Peller Signed-off-by: Emmanuel Grumbach Signed-off-by: Johannes Berg

mac80211: track whether to use channel contexts

2012-10-16T18:22:46Z

Depending on the driver, channel contexts may be used or not. If they are used, the driver must have support for hardware scan and remain-on-channel; otherwise the driver must not advertise support for multiple channels. Also prohibit WDS type interfaces when channel contexts are to be used as there's no clear definition of which channel they use. Signed-off-by: Johannes Berg

mac80211: use list_move instead of list_del/list_add

2012-09-06T09:55:47Z

Using list_move() instead of list_del() + list_add(). spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun Signed-off-by: Johannes Berg