<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/net/mac80211, branch v3.3.1</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>mac80211: Fix a warning on changing to monitor mode from STA</title>
<updated>2012-02-21T19:45:27+00:00</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-02-20T09:14:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0dee00686da88cc32753e02e4e8efdd9e326e4d2'/>
<id>0dee00686da88cc32753e02e4e8efdd9e326e4d2</id>
<content type='text'>
nothing needs to be done for monitor/AP_VLAN mode on calling
ieee80211_bss_info_change_notify -&gt; drv_bss_info_changed with the change
flag 'BSS_CHANGED_IDLE'. 'wl1271' seems to use BSS_CHANGED_IDLE only for
STA and IBSS mode. further the non-idle state of the monitor mode is
taken care by the 'count' variable which counts non-idle interfaces.
ieee80211_idle_off(local, "in use") will be called.
this fixes the following WARNING when we have initially STA mode
(network manager running) and not associated, and change it to monitor
mode with network manager disabled and bringing up the monitor mode.
this changes the idle state from 'true' (STA unassociated) to 'false'
(MONITOR mode)
exposed by the commit 405385f8ce7a2ed8f82e216d88b5282142e1288b
"mac80211: set bss_conf.idle when vif is connected"

	WARNING: net/mac80211/main.c:212
	ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]()
	Hardware name: 64756D6
	Pid: 3835, comm: ifconfig Tainted: G           O
	3.3.0-rc3-wl #9
	Call Trace:
	  [&lt;c0133b02&gt;] warn_slowpath_common+0x72/0xa0
	  [&lt;fc8e8c3f&gt;] ?
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;fc8e8c3f&gt;] ?
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;c0133b52&gt;] warn_slowpath_null+0x22/0x30
	  [&lt;fc8e8c3f&gt;]
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;fc8f9de3&gt;] __ieee80211_recalc_idle+0x113/0x430
	  [mac80211]
	  [&lt;fc8fabc6&gt;] ieee80211_do_open+0x156/0x7e0 [mac80211]
	  [&lt;fc8f8a25&gt;] ?
	  ieee80211_check_concurrent_iface+0x25/0x180 [mac80211]
	  [&lt;c015dd9f&gt;] ? raw_notifier_call_chain+0x1f/0x30
	  [&lt;fc8fb290&gt;] ieee80211_open+0x40/0x80 [mac80211]
	  [&lt;c05894f6&gt;] __dev_open+0x96/0xe0
	  [&lt;c068fba5&gt;] ? _raw_spin_unlock_bh+0x35/0x40
	  [&lt;c05881d9&gt;] __dev_change_flags+0x109/0x170
	  [&lt;c0589423&gt;] dev_change_flags+0x23/0x60
	  [&lt;c05f3770&gt;] devinet_ioctl+0x6a0/0x770

 ieee80211 phy0: device no longer idle - in use

Cc: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
nothing needs to be done for monitor/AP_VLAN mode on calling
ieee80211_bss_info_change_notify -&gt; drv_bss_info_changed with the change
flag 'BSS_CHANGED_IDLE'. 'wl1271' seems to use BSS_CHANGED_IDLE only for
STA and IBSS mode. further the non-idle state of the monitor mode is
taken care by the 'count' variable which counts non-idle interfaces.
ieee80211_idle_off(local, "in use") will be called.
this fixes the following WARNING when we have initially STA mode
(network manager running) and not associated, and change it to monitor
mode with network manager disabled and bringing up the monitor mode.
this changes the idle state from 'true' (STA unassociated) to 'false'
(MONITOR mode)
exposed by the commit 405385f8ce7a2ed8f82e216d88b5282142e1288b
"mac80211: set bss_conf.idle when vif is connected"

	WARNING: net/mac80211/main.c:212
	ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]()
	Hardware name: 64756D6
	Pid: 3835, comm: ifconfig Tainted: G           O
	3.3.0-rc3-wl #9
	Call Trace:
	  [&lt;c0133b02&gt;] warn_slowpath_common+0x72/0xa0
	  [&lt;fc8e8c3f&gt;] ?
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;fc8e8c3f&gt;] ?
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;c0133b52&gt;] warn_slowpath_null+0x22/0x30
	  [&lt;fc8e8c3f&gt;]
	  ieee80211_bss_info_change_notify+0x1cf/0x330 [mac80211]
	  [&lt;fc8f9de3&gt;] __ieee80211_recalc_idle+0x113/0x430
	  [mac80211]
	  [&lt;fc8fabc6&gt;] ieee80211_do_open+0x156/0x7e0 [mac80211]
	  [&lt;fc8f8a25&gt;] ?
	  ieee80211_check_concurrent_iface+0x25/0x180 [mac80211]
	  [&lt;c015dd9f&gt;] ? raw_notifier_call_chain+0x1f/0x30
	  [&lt;fc8fb290&gt;] ieee80211_open+0x40/0x80 [mac80211]
	  [&lt;c05894f6&gt;] __dev_open+0x96/0xe0
	  [&lt;c068fba5&gt;] ? _raw_spin_unlock_bh+0x35/0x40
	  [&lt;c05881d9&gt;] __dev_change_flags+0x109/0x170
	  [&lt;c0589423&gt;] dev_change_flags+0x23/0x60
	  [&lt;c05f3770&gt;] devinet_ioctl+0x6a0/0x770

 ieee80211 phy0: device no longer idle - in use

Cc: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: zero initialize count field in ieee80211_tx_rate</title>
<updated>2012-02-21T19:45:26+00:00</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-02-20T04:35:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8617b093d0031837a7be9b32bc674580cfb5f6b5'/>
<id>8617b093d0031837a7be9b32bc674580cfb5f6b5</id>
<content type='text'>
rate control algorithms concludes the rate as invalid
with rate[i].idx &lt; -1 , while they do also check for rate[i].count is
non-zero. it would be safer to zero initialize the 'count' field.
recently we had a ath9k rate control crash where the ath9k rate control
in ath_tx_status assumed to check only for rate[i].count being non-zero
in one instance and ended up in using invalid rate index for
'connection monitoring NULL func frames' which eventually lead to the crash.
thanks to Pavel Roskin for fixing it and finding the root cause.
https://bugzilla.redhat.com/show_bug.cgi?id=768639

Cc: stable@vger.kernel.org
Cc: Pavel Roskin &lt;proski@gnu.org&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
rate control algorithms concludes the rate as invalid
with rate[i].idx &lt; -1 , while they do also check for rate[i].count is
non-zero. it would be safer to zero initialize the 'count' field.
recently we had a ath9k rate control crash where the ath9k rate control
in ath_tx_status assumed to check only for rate[i].count being non-zero
in one instance and ended up in using invalid rate index for
'connection monitoring NULL func frames' which eventually lead to the crash.
thanks to Pavel Roskin for fixing it and finding the root cause.
https://bugzilla.redhat.com/show_bug.cgi?id=768639

Cc: stable@vger.kernel.org
Cc: Pavel Roskin &lt;proski@gnu.org&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: do not call rate control .tx_status before .rate_init</title>
<updated>2012-02-15T18:56:06+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2012-02-08T18:17:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=216c57b214bd621335ff698b475f6db2802502dc'/>
<id>216c57b214bd621335ff698b475f6db2802502dc</id>
<content type='text'>
Most rate control implementations assume .get_rate and .tx_status are only
called once the per-station data has been fully initialized.
minstrel_ht crashes if this assumption is violated.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Tested-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Most rate control implementations assume .get_rate and .tx_status are only
called once the per-station data has been fully initialized.
minstrel_ht crashes if this assumption is violated.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Tested-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: call rate control only after init</title>
<updated>2012-02-15T18:56:06+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-01-20T12:55:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4b5a433ae5348c23caa0b5f0a2fca7c342acb200'/>
<id>4b5a433ae5348c23caa0b5f0a2fca7c342acb200</id>
<content type='text'>
There are situations where we don't have the
necessary rate control information yet for
station entries, e.g. when associating. This
currently doesn't really happen due to the
dummy station handling; explicitly disabling
rate control when it's not initialised will
allow us to remove dummy stations.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are situations where we don't have the
necessary rate control information yet for
station entries, e.g. when associating. This
currently doesn't really happen due to the
dummy station handling; explicitly disabling
rate control when it's not initialised will
allow us to remove dummy stations.

Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Fix a rwlock bad magic bug</title>
<updated>2012-02-09T20:16:04+00:00</updated>
<author>
<name>Mohammed Shafi Shajakhan</name>
<email>mohammed@qca.qualcomm.com</email>
</author>
<published>2012-02-09T14:29:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b57e6b560fc2a2742910ac5ca0eb2c46e45aeac2'/>
<id>b57e6b560fc2a2742910ac5ca0eb2c46e45aeac2</id>
<content type='text'>
read_lock(&amp;tpt_trig-&gt;trig.leddev_list_lock) is accessed via the path
ieee80211_open (-&gt;) ieee80211_do_open (-&gt;) ieee80211_mod_tpt_led_trig
(-&gt;) ieee80211_start_tpt_led_trig (-&gt;) tpt_trig_timer before initializing
it.
the intilization of this read/write lock happens via the path
ieee80211_led_init (-&gt;) led_trigger_register, but we are doing
'ieee80211_led_init'  after 'ieeee80211_if_add' where we
register netdev_ops.
so we access leddev_list_lock before initializing it and causes the
following bug in chrome laptops with AR928X cards with the following
script

while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done

	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
	Call Trace:

	[&lt;8137b9df&gt;] rwlock_bug+0x3d/0x47
	[&lt;81179830&gt;] do_raw_read_lock+0x19/0x29
	[&lt;8137f063&gt;] _raw_read_lock+0xd/0xf
	[&lt;f9081957&gt;] tpt_trig_timer+0xc3/0x145 [mac80211]
	[&lt;f9081f3a&gt;] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
	[&lt;f9076a3f&gt;] ieee80211_do_open+0x11e/0x42e [mac80211]
	[&lt;f9075390&gt;] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
	[&lt;f9076d97&gt;] ieee80211_open+0x48/0x4c [mac80211]
	[&lt;812dbed8&gt;] __dev_open+0x82/0xab
	[&lt;812dc0c9&gt;] __dev_change_flags+0x9c/0x113
	[&lt;812dc1ae&gt;] dev_change_flags+0x18/0x44
	[&lt;8132144f&gt;] devinet_ioctl+0x243/0x51a
	[&lt;81321ba9&gt;] inet_ioctl+0x93/0xac
	[&lt;812cc951&gt;] sock_ioctl+0x1c6/0x1ea
	[&lt;812cc78b&gt;] ? might_fault+0x20/0x20
	[&lt;810b1ebb&gt;] do_vfs_ioctl+0x46e/0x4a2
	[&lt;810a6ebb&gt;] ? fget_light+0x2f/0x70
	[&lt;812ce549&gt;] ? sys_recvmsg+0x3e/0x48
	[&lt;810b1f35&gt;] sys_ioctl+0x46/0x69
	[&lt;8137fa77&gt;] sysenter_do_call+0x12/0x2

Cc: &lt;stable@vger.kernel.org&gt;
Cc: Gary Morain &lt;gmorain@google.com&gt;
Cc: Paul Stewart &lt;pstew@google.com&gt;
Cc: Abhijit Pradhan &lt;abhijit@qca.qualcomm.com&gt;
Cc: Vasanthakumar Thiagarajan &lt;vthiagar@qca.qualcomm.com&gt;
Cc: Rajkumar Manoharan &lt;rmanohar@qca.qualcomm.com&gt;
Acked-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Tested-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
read_lock(&amp;tpt_trig-&gt;trig.leddev_list_lock) is accessed via the path
ieee80211_open (-&gt;) ieee80211_do_open (-&gt;) ieee80211_mod_tpt_led_trig
(-&gt;) ieee80211_start_tpt_led_trig (-&gt;) tpt_trig_timer before initializing
it.
the intilization of this read/write lock happens via the path
ieee80211_led_init (-&gt;) led_trigger_register, but we are doing
'ieee80211_led_init'  after 'ieeee80211_if_add' where we
register netdev_ops.
so we access leddev_list_lock before initializing it and causes the
following bug in chrome laptops with AR928X cards with the following
script

while true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
done

	BUG: rwlock bad magic on CPU#1, wpa_supplicant/358, f5b9eccc
	Pid: 358, comm: wpa_supplicant Not tainted 3.0.13 #1
	Call Trace:

	[&lt;8137b9df&gt;] rwlock_bug+0x3d/0x47
	[&lt;81179830&gt;] do_raw_read_lock+0x19/0x29
	[&lt;8137f063&gt;] _raw_read_lock+0xd/0xf
	[&lt;f9081957&gt;] tpt_trig_timer+0xc3/0x145 [mac80211]
	[&lt;f9081f3a&gt;] ieee80211_mod_tpt_led_trig+0x152/0x174 [mac80211]
	[&lt;f9076a3f&gt;] ieee80211_do_open+0x11e/0x42e [mac80211]
	[&lt;f9075390&gt;] ? ieee80211_check_concurrent_iface+0x26/0x13c [mac80211]
	[&lt;f9076d97&gt;] ieee80211_open+0x48/0x4c [mac80211]
	[&lt;812dbed8&gt;] __dev_open+0x82/0xab
	[&lt;812dc0c9&gt;] __dev_change_flags+0x9c/0x113
	[&lt;812dc1ae&gt;] dev_change_flags+0x18/0x44
	[&lt;8132144f&gt;] devinet_ioctl+0x243/0x51a
	[&lt;81321ba9&gt;] inet_ioctl+0x93/0xac
	[&lt;812cc951&gt;] sock_ioctl+0x1c6/0x1ea
	[&lt;812cc78b&gt;] ? might_fault+0x20/0x20
	[&lt;810b1ebb&gt;] do_vfs_ioctl+0x46e/0x4a2
	[&lt;810a6ebb&gt;] ? fget_light+0x2f/0x70
	[&lt;812ce549&gt;] ? sys_recvmsg+0x3e/0x48
	[&lt;810b1f35&gt;] sys_ioctl+0x46/0x69
	[&lt;8137fa77&gt;] sysenter_do_call+0x12/0x2

Cc: &lt;stable@vger.kernel.org&gt;
Cc: Gary Morain &lt;gmorain@google.com&gt;
Cc: Paul Stewart &lt;pstew@google.com&gt;
Cc: Abhijit Pradhan &lt;abhijit@qca.qualcomm.com&gt;
Cc: Vasanthakumar Thiagarajan &lt;vthiagar@qca.qualcomm.com&gt;
Cc: Rajkumar Manoharan &lt;rmanohar@qca.qualcomm.com&gt;
Acked-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Tested-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: Mohammed Shafi Shajakhan &lt;mohammed@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: timeout a single frame in the rx reorder buffer</title>
<updated>2012-02-01T20:26:00+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2012-02-01T16:48:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07ae2dfcf4f7143ce191c6436da1c33f179af0d6'/>
<id>07ae2dfcf4f7143ce191c6436da1c33f179af0d6</id>
<content type='text'>
The current code checks for stored_mpdu_num &gt; 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current code checks for stored_mpdu_num &gt; 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: set bss_conf.idle when vif is connected</title>
<updated>2012-01-24T19:47:09+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2012-01-11T11:11:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=405385f8ce7a2ed8f82e216d88b5282142e1288b'/>
<id>405385f8ce7a2ed8f82e216d88b5282142e1288b</id>
<content type='text'>
__ieee80211_recalc_idle() iterates through the vifs,
sets bss_conf.idle = true if they are disconnected,
and increases "count" if they are not (which later
gets evaluated in order to determine whether the
device is idle).

However, the loop doesn't set bss_conf.idle = false
(along with increasing "count"), causing the device
idle state and the vif idle state to get out of sync
in some cases.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__ieee80211_recalc_idle() iterates through the vifs,
sets bss_conf.idle = true if they are disconnected,
and increases "count" if they are not (which later
gets evaluated in order to determine whether the
device is idle).

However, the loop doesn't set bss_conf.idle = false
(along with increasing "count"), causing the device
idle state and the vif idle state to get out of sync
in some cases.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: update oper_channel on ibss join</title>
<updated>2012-01-24T19:47:09+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2012-01-10T13:19:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ba1960257c5980f9b58057995ce3394bd8e48ca3'/>
<id>ba1960257c5980f9b58057995ce3394bd8e48ca3</id>
<content type='text'>
Commit 13c40c5 ("mac80211: Add HT operation modes for IBSS") broke
ibss operation by mistakenly removing the local-&gt;oper_channel
update (causing ibss to start on the wrong channel). fix it.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Acked-by: Simon Wunderlich &lt;siwu@hrz.tu-chemnitz.de&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 13c40c5 ("mac80211: Add HT operation modes for IBSS") broke
ibss operation by mistakenly removing the local-&gt;oper_channel
update (causing ibss to start on the wrong channel). fix it.

Signed-off-by: Eliad Peller &lt;eliad@wizery.com&gt;
Acked-by: Simon Wunderlich &lt;siwu@hrz.tu-chemnitz.de&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: fix work removal on deauth request</title>
<updated>2012-01-18T19:38:06+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2012-01-18T13:10:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bc4934bc61d0a11fd62c5187ff83645628f8be8b'/>
<id>bc4934bc61d0a11fd62c5187ff83645628f8be8b</id>
<content type='text'>
When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.

In the case Pontus found, the problem manifested
itself as such:

authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)

It could also happen differently if the driver
uses the tx_sync callback.

We can't just call the -&gt;done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.

Cc: stable@vger.kernel.org
Reported-by: Pontus Fuchs &lt;pontus.fuchs@gmail.com&gt;
Tested-by: Pontus Fuchs &lt;pontus.fuchs@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When deauth is requested while an auth or assoc
work item is in progress, we currently delete it
without regard for any state it might need to
clean up. Fix it by cleaning up for those items.

In the case Pontus found, the problem manifested
itself as such:

authenticate with 00:23:69:aa:dd:7b (try 1)
authenticated
failed to insert Dummy STA entry for the AP (error -17)
deauthenticating from 00:23:69:aa:dd:7b by local choice (reason=2)

It could also happen differently if the driver
uses the tx_sync callback.

We can't just call the -&gt;done() method of the work
items because that will lock up due to the locking
in cfg80211. This fix isn't very clean, but that
seems acceptable since I have patches pending to
remove this code completely.

Cc: stable@vger.kernel.org
Reported-by: Pontus Fuchs &lt;pontus.fuchs@gmail.com&gt;
Tested-by: Pontus Fuchs &lt;pontus.fuchs@gmail.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mac80211: Use the right headroom size for mesh mgmt frames</title>
<updated>2012-01-18T19:38:06+00:00</updated>
<author>
<name>Javier Cardona</name>
<email>javier@cozybit.com</email>
</author>
<published>2012-01-18T02:17:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65e8b0ccb6cf176f8eddb1b05534be46580da9dd'/>
<id>65e8b0ccb6cf176f8eddb1b05534be46580da9dd</id>
<content type='text'>
Use local-&gt;tx_headroom instad of local-&gt;hw.extra_tx_headroom.
local-&gt;tx_headroom is the max of hw.extra_tx_headroom required by the
driver and the headroom required by mac80211 for status reporting.  On
drivers where hw.extra_tx_headroom is smaller than what mac80211
requires (e.g. ath5k), we would not reserve sufficient buffer space to
report tx status.

Also, don't reserve local-&gt;tx_headroom + local-&gt;hw.extra_tx_headroom.

Reported-by: Simon Morgenthaler &lt;s.morgenthaler@students.unibe.ch&gt;
Reported-by: Kai Scharwies &lt;kai@scharwies.de&gt;
Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use local-&gt;tx_headroom instad of local-&gt;hw.extra_tx_headroom.
local-&gt;tx_headroom is the max of hw.extra_tx_headroom required by the
driver and the headroom required by mac80211 for status reporting.  On
drivers where hw.extra_tx_headroom is smaller than what mac80211
requires (e.g. ath5k), we would not reserve sufficient buffer space to
report tx status.

Also, don't reserve local-&gt;tx_headroom + local-&gt;hw.extra_tx_headroom.

Reported-by: Simon Morgenthaler &lt;s.morgenthaler@students.unibe.ch&gt;
Reported-by: Kai Scharwies &lt;kai@scharwies.de&gt;
Signed-off-by: Javier Cardona &lt;javier@cozybit.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
