<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/net/mac80211, branch linux-3.15.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.15.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=linux-3.15.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2014-08-07T23:53:51+00:00</updated>
<entry>
<title>Revert "mac80211: move "bufferable MMPDU" check to fix AP mode scan"</title>
<updated>2014-08-07T23:53:51+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-07-07T10:01:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8c0414e0272172f383b6daa4398f0b3a42e3ea0f'/>
<id>urn:sha1:8c0414e0272172f383b6daa4398f0b3a42e3ea0f</id>
<content type='text'>
commit 08b9939997df30e42a228e1ecb97f99e9c8ea84e upstream.

This reverts commit 277d916fc2e959c3f106904116bb4f7b1148d47a as it was
at least breaking iwlwifi by setting the IEEE80211_TX_CTL_NO_PS_BUFFER
flag in all kinds of interface modes, not only for AP mode where it is
appropriate.

To avoid reintroducing the original problem, explicitly check for probe
request frames in the multicast buffering code.

Fixes: 277d916fc2e9 ("mac80211: move "bufferable MMPDU" check to fix AP mode scan")
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: fix a memory leak on sta rate selection table</title>
<updated>2014-07-09T18:21:28+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2014-05-27T20:33:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=699012e1775dbf7b971e9bcf3269fa83fab4aa0f'/>
<id>urn:sha1:699012e1775dbf7b971e9bcf3269fa83fab4aa0f</id>
<content type='text'>
commit 53d045258ee2e38b1e882617cb0799a04d05f5fa upstream.

If the rate control algorithm uses a selection table, it
is leaked when the station is destroyed - fix that.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Reported-by: Christophe Prévotaux &lt;cprevotaux@nltinc.com&gt;
Fixes: 0d528d85c519 ("mac80211: improve the rate control API")
[add commit log entry, remove pointless NULL check]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: don't check netdev state for debugfs read/write</title>
<updated>2014-07-09T18:21:28+00:00</updated>
<author>
<name>Arik Nemtsov</name>
<email>arik@wizery.com</email>
</author>
<published>2014-05-26T11:40:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1c95722fa828807fe982ed8ecbfcf74657e8d630'/>
<id>urn:sha1:1c95722fa828807fe982ed8ecbfcf74657e8d630</id>
<content type='text'>
commit 923eaf367206e01f22c97aee22300e332d071916 upstream.

Doing so will lead to an oops for a p2p-dev interface, since it has
no netdev.

Signed-off-by: Arik Nemtsov &lt;arikx.nemtsov@intel.com&gt;
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mac80211: fix IBSS join by initializing last_scan_completed</title>
<updated>2014-07-09T18:21:28+00:00</updated>
<author>
<name>Krzysztof Hałasa</name>
<email>khalasa@piap.pl</email>
</author>
<published>2014-05-26T12:14:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=894793a948a9350951abc9bd190210d92e81814b'/>
<id>urn:sha1:894793a948a9350951abc9bd190210d92e81814b</id>
<content type='text'>
commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream.

Without this fix, freshly rebooted Linux creates a new IBSS
instead of joining an existing one. Only when jiffies counter
overflows after 5 minutes the IBSS can be successfully joined.

Signed-off-by: Krzysztof Hałasa &lt;khalasa@piap.pl&gt;
[edit commit message slightly]
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>net: force a list_del() in unregister_netdevice_many()</title>
<updated>2014-06-26T19:17:33+00:00</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2014-06-06T13:44:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=86a60ac4965c3057031d9a4930d5c64832061fbc'/>
<id>urn:sha1:86a60ac4965c3057031d9a4930d5c64832061fbc</id>
<content type='text'>
[ Upstream commit 87757a917b0b3c0787e0563c679762152be81312 ]

unregister_netdevice_many() API is error prone and we had too
many bugs because of dangling LIST_HEAD on stacks.

See commit f87e6f47933e3e ("net: dont leave active on stack LIST_HEAD")

In fact, instead of making sure no caller leaves an active list_head,
just force a list_del() in the callee. No one seems to need to access
the list after unregister_netdevice_many()

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mac80211: fix on-channel remain-on-channel</title>
<updated>2014-05-14T13:48:38+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-05-14T13:34:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b4b177a5556a686909e643f1e9b6434c10de079f'/>
<id>urn:sha1:b4b177a5556a686909e643f1e9b6434c10de079f</id>
<content type='text'>
Jouni reported that if a remain-on-channel was active on the
same channel as the current operating channel, then the ROC
would start, but any frames transmitted using mgmt-tx on the
same channel would get delayed until after the ROC.

The reason for this is that the ROC starts, but doesn't have
any handling for "remain on the same channel", so it stops
the interface queues. The later mgmt-tx then puts the frame
on the interface queues (since it's on the current operating
channel) and thus they get delayed until after the ROC.

To fix this, add some logic to handle remaining on the same
channel specially and not stop the queues etc. in this case.
This not only fixes the bug but also improves behaviour in
this case as data frames etc. can continue to flow.

Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen &lt;j@w1.fi&gt;
Tested-by: Jouni Malinen &lt;j@w1.fi&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix suspend vs. association race</title>
<updated>2014-05-13T11:58:16+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2014-05-13T09:54:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c52666aef9f2dff39276eb53f15d99e2e229870f'/>
<id>urn:sha1:c52666aef9f2dff39276eb53f15d99e2e229870f</id>
<content type='text'>
If the association is in progress while we suspend, the
stack will be in a messed up state. Clean it before we
suspend.

This patch completes Johannes's patch:

1a1cb744de160ee70086a77afff605bbc275d291
Author: Johannes Berg &lt;johannes.berg@intel.com&gt;

    mac80211: fix suspend vs. authentication race

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 12e7f517029d ("mac80211: cleanup generic suspend/resume procedures")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix vif name tracing</title>
<updated>2014-05-09T12:35:40+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2014-02-26T12:46:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f9ac71bfcc5c937ff02765dc316cf5bc01d21d97'/>
<id>urn:sha1:f9ac71bfcc5c937ff02765dc316cf5bc01d21d97</id>
<content type='text'>
If sdata doesn't have a valid dev (e.g. in case of monitor
vif), the vif_name field was initialized with (a length of)
some short string, but later was set to a different,
potentially larger one.

This resulted in out-of-bounds write, which usually
appeared as garbage in the trace log.

Simply trace sdata-&gt;name, as it should always have the
correct name for both cases.

Signed-off-by: Eliad Peller &lt;eliadx.peller@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: allow VHT with peers not capable of 40MHz</title>
<updated>2014-05-09T07:56:53+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2014-05-09T07:56:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4a817aa78f573c6964f16d9aea3d0d10a226ade4'/>
<id>urn:sha1:4a817aa78f573c6964f16d9aea3d0d10a226ade4</id>
<content type='text'>
There are two (related) issues with this.

One case, reported by Michal, is related to hostap: it unsets the
20/40 capability bit for stations that associate when it's in 20
MHz mode.

The other case, reported by Eyal, is that some APs like Netgear
R6300v2 and probably others based on the BCM4360 chipset can be
configured for doing VHT at 20Mhz. In this case the beacon has
a VHT IE but the HT cap indicates transmitter only support 20Mhz.

In both of these cases, we currently avoid VHT and use only HT
this means we can't use the highest rates (MCS8), so fixing this
leads to throughput improvements.

Reported-by: Michal Kazior &lt;michal.kazior@tieto.com&gt;
Reported-by: Eyal Shapira &lt;eyal@wizery.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>mac80211: fix nested rtnl locking on ieee80211_reconfig</title>
<updated>2014-05-05T13:14:58+00:00</updated>
<author>
<name>Eliad Peller</name>
<email>eliad@wizery.com</email>
</author>
<published>2014-04-30T13:14:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e669ba2d06c6195662601956454ac959892f0762'/>
<id>urn:sha1:e669ba2d06c6195662601956454ac959892f0762</id>
<content type='text'>
ieee80211_reconfig already holds rtnl, so calling
cfg80211_sched_scan_stopped results in deadlock.

Use the rtnl-version of this function instead.

Fixes: d43c6b6 ("mac80211: reschedule sched scan after HW restart")
Cc: stable@vger.kernel.org (3.14+)
Signed-off-by: Eliad Peller &lt;eliadx.peller@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
