linux-stable.git/net/mac80211, branch v4.6.2 Linux kernel stable tree mac80211: fix statistics leak if dev_alloc_name() fails 2016-04-27T08:06:58+00:00 Johannes Berg johannes.berg@intel.com 2016-04-26T11:47:08+00:00 e6436be21e77e3659b4ff7e357ab5a8342d132d2 In the case that dev_alloc_name() fails, e.g. because the name was given by the user and already exists, we need to clean up properly and free the per-CPU statistics. Fix that. Cc: stable@vger.kernel.org Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics") Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
In the case that dev_alloc_name() fails, e.g. because the name was
given by the user and already exists, we need to clean up properly
and free the per-CPU statistics. Fix that.

Cc: stable@vger.kernel.org
Fixes: 5a490510ba5f ("mac80211: use per-CPU TX/RX statistics")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: fix "warning: ‘target_metric’ may be used uninitialized" 2016-04-06T13:10:25+00:00 Jeff Mahoney jeffm@suse.com 2016-04-04T18:15:23+00:00 b4201cc4fc6e1c57d6d306b1f787865043d60129 This fixes: net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function target_metric is only consumed when reply = true so no bug exists here, but not all versions of gcc realize it. Initialize to 0 to remove the warning. Signed-off-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
This fixes:

net/mac80211/mesh_hwmp.c:603:26: warning: ‘target_metric’ may be used uninitialized in this function

target_metric is only consumed when reply = true so no bug exists here,
but not all versions of gcc realize it.  Initialize to 0 to remove the
warning.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: close the SP when we enqueue frames during the SP 2016-04-05T09:33:49+00:00 Emmanuel Grumbach emmanuel.grumbach@intel.com 2016-03-17T14:51:42+00:00 f6d4671a08810ff5111099dd1febe57e7eb9ba59 Since we enqueued the frame that was supposed to be sent during the SP, and that frame may very well cary the IEEE80211_TX_STATUS_EOSP bit, we may never close the SP (WLAN_STA_SP will never be cleared). If that happens, we will not open any new SP and will never respond to any poll frame from the client. Clear WLAN_STA_SP manually if a frame that was polled during the SP is queued because of a starting A-MPDU session. The client may not see the EOSP bit, but it will at least be able to poll new frames in another SP. Reported-by: Alesya Shapira <alesya.shapira@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> [remove erroneous comment] Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Since we enqueued the frame that was supposed to be sent
during the SP, and that frame may very well cary the
IEEE80211_TX_STATUS_EOSP bit, we may never close the SP
(WLAN_STA_SP will never be cleared). If that happens, we
will not open any new SP and will never respond to any poll
frame from the client.
Clear WLAN_STA_SP manually if a frame that was polled during
the SP is queued because of a starting A-MPDU session. The
client may not see the EOSP bit, but it will at least be
able to poll new frames in another SP.

Reported-by: Alesya Shapira <alesya.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
[remove erroneous comment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: Fix BW upgrade for TDLS peers 2016-04-05T09:26:33+00:00 Ilan Peer ilan.peer@intel.com 2016-03-08T11:35:31+00:00 4b559ec0bfc3a9f41a127cea6964f38b2b4bb323 It is possible that the station is connected to an AP with bandwidth of 80+80MHz or 160MHz. In such cases there is no need to perform an upgrade as the maximal supported bandwidth is 80MHz. In addition, when upgrading and setting center_freq1 and bandwidth to 80MHz also set center_freq2 to 0. Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible" Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
It is possible that the station is connected to an AP
with bandwidth of 80+80MHz or 160MHz. In such cases
there is no need to perform an upgrade as the maximal
supported bandwidth is 80MHz.

In addition, when upgrading and setting center_freq1
and bandwidth to 80MHz also set center_freq2 to 0.

Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible"
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: don't send deferred frames outside the SP 2016-04-05T09:16:50+00:00 Emmanuel Grumbach emmanuel.grumbach@intel.com 2016-03-17T14:51:41+00:00 facde7f332f91353c7a6d34c9cff6b329cc0c3ab Frames that are sent between ampdu_action(IEEE80211_AMPDU_TX_START) and the move to the HT_AGG_STATE_OPERATIONAL state are buffered. If we try to start an A-MPDU session while the peer is sleeping and polling frames with U-APSD, we may have frames that will be buffered by ieee80211_tx_prep_agg. These frames have IEEE80211_TX_CTL_NO_PS_BUFFER set since they are sent to a sleeping client and possibly IEEE80211_TX_STATUS_EOSP. If the frame is buffered, we need clear these two flags since they will be re-sent after the move to HT_AGG_STATE_OPERATIONAL state which is very likely to happen after the SP ends. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Frames that are sent between
ampdu_action(IEEE80211_AMPDU_TX_START) and the move to the
HT_AGG_STATE_OPERATIONAL state are buffered.
If we try to start an A-MPDU session while the peer is
sleeping and polling frames with U-APSD, we may have frames
that will be buffered by ieee80211_tx_prep_agg. These frames
have IEEE80211_TX_CTL_NO_PS_BUFFER set since they are sent to
a sleeping client and possibly IEEE80211_TX_STATUS_EOSP.
If the frame is buffered, we need clear these two flags
since they will be re-sent after the move to
HT_AGG_STATE_OPERATIONAL state which is very likely to
happen after the SP ends.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: remove description of dropped member 2016-04-05T09:12:09+00:00 Luis de Bethencourt luisbg@osg.samsung.com 2016-03-18T19:23:18+00:00 c2d45923e3df43b58bddf80debd8e22edd5077bf Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd") removed the member from the sta_info struct but the description stayed lingering. Remove it. Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
Commit 976bd9efdae6 ("mac80211: move beacon_loss_count into ifmgd")
removed the member from the sta_info struct but the description stayed
lingering. Remove it.

Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: ensure no limits on station rhashtable 2016-04-05T09:06:58+00:00 Ben Greear greearb@candelatech.com 2016-04-01T21:13:31+00:00 b6bf8c688e07c056f3059d870f6db44777259fe7 By default, the rhashtable logic will fail to insert objects if the key-chains are too long and un-balanced. In the degenerate case where mac80211 is creating many virtual interfaces connected to the same peer(s), this case can happen. St insecure_elasticity to true to allow chains to grow as long as needed. Signed-off-by: Ben Greear <greearb@candelatech.com> [remove message, change commit message slightly] Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
By default, the rhashtable logic will fail to insert
objects if the key-chains are too long and un-balanced.

In the degenerate case where mac80211 is creating many
virtual interfaces connected to the same peer(s), this
case can happen.

St insecure_elasticity to true to allow chains to grow
as long as needed.

Signed-off-by: Ben Greear <greearb@candelatech.com>
[remove message, change commit message slightly]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: properly deal with station hashtable insert errors 2016-04-05T08:58:30+00:00 Johannes Berg johannes.berg@intel.com 2016-03-31T15:22:45+00:00 62b14b241ca6f790a17ccd9dd9f62ce1b006d406 The original hand-implemented hash-table in mac80211 couldn't result in insertion errors, and while converting to rhashtable I evidently forgot to check the errors. This surfaced now only because Ben is adding many identical keys and that resulted in hidden insertion errors. Cc: stable@vger.kernel.org Fixes: 7bedd0cfad4e1 ("mac80211: use rhashtable for station table") Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
The original hand-implemented hash-table in mac80211 couldn't result
in insertion errors, and while converting to rhashtable I evidently
forgot to check the errors.

This surfaced now only because Ben is adding many identical keys and
that resulted in hidden insertion errors.

Cc: stable@vger.kernel.org
Fixes: 7bedd0cfad4e1 ("mac80211: use rhashtable for station table")
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: recalc min_def chanctx even when chandef is identical 2016-04-05T08:51:08+00:00 Arik Nemtsov arik@wizery.com 2016-03-02T21:28:33+00:00 aa507a7bc5ab7513b83fc37ed040b5254737a518 The min_def chanctx is affected not only by the current chandef, but sometimes also by other stations on the vif. There's a valid scenario where a TDLS peer can widen its BW, thereby causing the min_def to increase. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
The min_def chanctx is affected not only by the current chandef, but
sometimes also by other stations on the vif. There's a valid scenario
where a TDLS peer can widen its BW, thereby causing the min_def
to increase.

Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: TDLS: change BW calculation for WIDER_BW peers 2016-04-05T08:50:52+00:00 Arik Nemtsov arik@wizery.com 2016-03-02T21:28:32+00:00 59021c675995281d453eee45b3e2e1e3edbc0ec2 The previous approach simply ignored chandef restrictions when calculating the appropriate peer BW for a WIDER_BW peer. This could result in a regulatory violation if both peers indicated 80MHz support, but the regdomain forbade it. Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from the chandef width at first. If during TDLS negotiation the chandef width is upgraded, update the peer's BW to match. Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible") Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> 
The previous approach simply ignored chandef restrictions when calculating
the appropriate peer BW for a WIDER_BW peer. This could result in a
regulatory violation if both peers indicated 80MHz support, but the
regdomain forbade it.

Change the approach to setting a WIDER_BW peer's BW. Don't exempt it from
the chandef width at first. If during TDLS negotiation the chandef width
is upgraded, update the peer's BW to match.

Fixes: 0fabfaafec3a ("mac80211: upgrade BW of TDLS peers when possible")
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>