Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 2月, 2021 1 次提交
  3. 12 12月, 2020 1 次提交
  5. 10 12月, 2020 2 次提交
  7. 11 11月, 2020 1 次提交
  9. 09 10月, 2020 3 次提交
  11. 02 10月, 2020 3 次提交
  13. 23 6月, 2020 1 次提交
  15. 10 6月, 2020 1 次提交
  17. 29 5月, 2020 1 次提交
  19. 08 5月, 2020 3 次提交
  21. 21 4月, 2020 2 次提交
  23. 04 2月, 2020 1 次提交
    • L
      iwlwifi: don't throw error when trying to remove IGTK · 197288d5
      由 Luca Coelho 提交于 
      The IGTK keys are only removed by mac80211 after it has already
removed the AP station.  This causes the driver to throw an error
because mac80211 is trying to remove the IGTK when the station doesn't
exist anymore.

The firmware is aware that the station has been removed and can deal
with it the next time we try to add an IGTK for a station, so we
shouldn't try to remove the key if the station ID is
IWL_MVM_INVALID_STA.  Do this by removing the check for mvm_sta before
calling iwl_mvm_send_sta_igtk() and check return from that function
gracefully if the station ID is invalid.

Cc: stable@vger.kernel.org # 4.12+
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      197288d5
  25. 23 10月, 2019 1 次提交
  27. 04 10月, 2019 1 次提交
  29. 06 9月, 2019 6 次提交
  31. 31 7月, 2019 4 次提交
  33. 19 4月, 2019 2 次提交
  35. 03 4月, 2019 2 次提交
    • J
      iwlwifi: mvm: IBSS: use BE FIFO for multicast · 192a7e1f
      由 Johannes Berg 提交于 
      Back in commit 4d339989 ("iwlwifi: mvm: support ibss in dqa mode")
we changed queue selection for IBSS to be:

    if (ieee80211_is_probe_resp(fc) || ieee80211_is_auth(fc) ||
        ieee80211_is_deauth(fc))
            return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;
    if (info->hw_queue == info->control.vif->cab_queue)
            return info->hw_queue;
    return IWL_MVM_DQA_AP_PROBE_RESP_QUEUE;

Clearly, the thought at the time must've been that mac80211 will
select the hw_queue as the cab_queue, so that we'll return and use
that, where we store the multicast queue for IBSS. This, however,
isn't true because mac80211 doesn't implement powersave for IBSS
and thus selects the normal IBSS interface AC queue (best effort).

This therefore always used the probe response queue, which maps to
the BE FIFO.

In commit cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model")
we rethought this code, and as a consequence now started mapping the
multicast traffic to the multicast hardware queue since we no longer
relied on mac80211 selecting the queue, doing it ourselves instead.
This queue is mapped to the MCAST FIFO. however, this isn't actually
enabled/controlled by the firmware in IBSS mode because we don't
implement powersave, and frames from this queue can never go out in
this case.

Therefore, we got queue hang reports such as
https://bugzilla.kernel.org/show_bug.cgi?id=201707

Fix this by mapping the multicast queue to the BE FIFO in IBSS so
that all the frames can go out.

Fixes: cfbc6c4c ("iwlwifi: mvm: support mac80211 TXQs model")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      192a7e1f
    • J
      iwlwifi: mvm: avoid possible deadlock in TX path · f5ae2f93
      由 Johannes Berg 提交于 
      iwl_mvm_tx_mpdu() may run from iwl_mvm_add_new_dqa_stream_wk(), where
soft-IRQs aren't disabled. In this case, it may hold the station lock
and be interrupted by a soft-IRQ that also wants to acquire said lock,
leading to a deadlock.

Fix it by disabling soft-IRQs in iwl_mvm_add_new_dqa_stream_wk().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      f5ae2f93
  37. 22 3月, 2019 1 次提交
    • J
      iwlwifi: mvm: fix TX crypto on 22560+ devices · 475c6bde
      由 Johannes Berg 提交于 
      In the old days, we could transmit with HW crypto with an arbitrary
key by filling it into TX_CMD. This was broken first with the advent
of CCMP/GCMP-256 keys which don't fit there.

This was broken *again* with the newer TX_CMD format on 22560+,
where we simply cannot pass key material anymore. However, we forgot
to update all the cases when we get a key from mac80211 and don't
program it into the hardware but still return 0 for HW crypto on TX.

In AP mode with WEP, we tried to fix this by programming the keys
separately for each station later, but this ultimately turns out to
be buggy, for example now it leaks memory when we have more than one
WEP key.

Fix this by simply using only SW crypto for WEP in newer devices by
returning -EOPNOTSUPP instead of trying to program WEP keys later.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      475c6bde
  39. 14 2月, 2019 1 次提交
  41. 04 2月, 2019 2 次提交
    • J
      iwlwifi: mvm: remove redundant condition · f992c61d
      由 Johannes Berg 提交于 
      In iwl_mvm_sta_alloc_queue_tvqm(), we know that we have a
station, so no need to check it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      f992c61d
    • E
      iwlwifi: mvm: fix AP mode in WEP · 28916a16
      由 Emmanuel Grumbach 提交于 
      Recently we started to send the WEP keys to the firmware so
that we could use hardware Tx encryption also on newer
devices that require the keys to be installed in the firmware
for encryption (as opposed to older devices that can get
the key in the Tx command for each Tx).

When we implemented that, we forgot to remove the key when
we remove a station leading to a situation where a station
that connects and disconnects a lot of times exhausts the
key database inside the firmware.

A fix was made for that, but we always removed the same
key: mvmvif->ap_wep_key which means that we removed the
same key entry in the firmware. This can make sense since
in WEP, the key is the same for all the stations, but the
internal implementation of iwl_mvm_set_sta_key and
iwl_mvm_remove_sta_key assumes that each station uses a
different key in the firmware's key database.

So now we got to the situation where we have a single
ieee80211_key_conf instance that means, a single
ieee80211_key_conf.hw_key_idx index for several stations
and hence for several keys.
ieee80211_key_conf.hw_key_idx is set to 0 when the first
station associates, and then it is overwritten to 1 when
the second station associates which is a buggy of course.
This led to the following message upon the removal of the
second station:

iwlwifi 0000:00:03.0: offset 1 not used in fw key table.
WARNING: CPU: 2 PID: 27883 at net/mac80211/sta_info.c:1122 __sta_info_destroy_part2+0x16b/0x180 [mac80211]
RIP: 0010:__sta_info_destroy_part2+0x16b/0x180 [mac80211]
 Call Trace:
  __sta_info_destroy+0x2a/0x40 [mac80211]
  sta_info_destroy_addr_bss+0x38/0x60 [mac80211]
  ieee80211_del_station+0x1d/0x30 [mac80211]
  nl80211_del_station+0xe0/0x1f0 [cfg80211]

Fix this by copying the ieee80211_key_conf structure for
each and every station. This is the easiest way to properly
remove the keys with the right index. Another solution
would have been to allow several stations to use the same
key offset in the firmware. That would require to change
the way we track keys in iwlmvm and not really worth it.

Also, maintain correctly fw_key_table when we add a key
for the multicast station.
Remove the key when we remove the multicast station.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Fixes: 337bfc98 ("iwlwifi: mvm: set wep key for all stations in soft ap mode")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      28916a16