Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 12月, 2019 8 次提交
    • J
      iwlwifi: pcie: extend hardware workaround to context-info · d84a7a65
      由 Johannes Berg 提交于 
      After more investigation on the hardware side, it appears that the
hardware bug regarding 2^32 boundary reaching/crossing also affects
other uses of the DMA engine, in particular the ones triggered by
the context-info (image loader) mechanism.

It also turns out that the bug only affects devices with gen2 TX
hardware engine, so we don't need to change context info for gen3.
The TX path workarounds are simpler to still keep for both though.

Add the workaround to that code as well; this is a lot simpler as
we have just a single way to allocate DMA memory there.

I made the algorithm recursive (with a small limit) since it's
actually (almost) impossible to hit this today - dma_alloc_coherent
is currently documented to always return 32-bit addressable memory
regardless of the DMA mask for it, and so we could only get REALLY
unlucky to get the very last page in that area.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      d84a7a65
    • H
      iwlwifi: Don't ignore the cap field upon mcc update · 2763bba6
      由 Haim Dreyfuss 提交于 
      When receiving a new MCC driver get all the data about the new country
code and its regulatory information.
Mistakenly, we ignored the cap field, which includes global regulatory
information which should be applies to every channel.
Fix it.
Signed-off-by: NHaim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      2763bba6
    • J
      iwlwifi: mvm: report TX rate to mac80211 directly for RS offload · ed780545
      由 Johannes Berg 提交于 
      If we have offloaded rate scaling, which is always true for those
devices supporting HE, then report the TX rate directly from the
data the firmware gives us, instead of only passing it to mac80211
on frame status only and for it to track it.

First of all, this makes us always report the last good rate that
the rate scaling algorithm picked, which is better than reporting
the last rate for any frame since management frames etc. are sent
with very low rates and could interfere.

Additionally, this allows us to properly report HE rates, though
in case there's a lot of trigger-based traffic, we don't get any
choice in the rates and don't report that properly right now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ed780545
    • L
      iwlwifi: mvm: fix NVM check for 3168 devices · b3f20e09
      由 Luca Coelho 提交于 
      We had a check on !NVM_EXT and then a check for NVM_SDP in the else
block of this if.  The else block, obviously, could only be reached if
using NVM_EXT, so it would never be NVM_SDP.

Fix that by checking whether the nvm_type is IWL_NVM instead of
checking for !IWL_NVM_EXT to solve this issue.
Reported-by: NStefan Sperling <stsp@stsp.name>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      b3f20e09
    • L
      iwlwifi: fix TLV fragment allocation loop · 4f565ee2
      由 Luca Coelho 提交于 
      In the allocation loop, "pages" will never become zero (because of the
DIV_ROUND_UP), so if we can't allocate any size and pages becomes 1,
we will keep trying to allocate 1 page until it succeeds.  And in that
case, as coverity reported, block will never be NULL.
Reported-by: Ncoverity-bot <keescook+coverity-bot@chromium.org>
Addresses-Coverity-ID: 1487402 ("Control flow issues")
Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Fixes: 14124b25 ("iwlwifi: dbg_ini: implement monitor allocation flow")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      4f565ee2
    • J
      iwlwifi: pcie: allocate smaller dev_cmd for TX headers · a89c72ff
      由 Johannes Berg 提交于 
      As noted in the previous commit, due to the way we allocate the
dev_cmd headers with 324 byte size, and 4/8 byte alignment, the
part we use of them (bytes 20..40-68) could still cross a page
and thus 2^32 boundary.

Address this by using alignment to ensure that the allocation
cannot cross a page boundary, on hardware that's affected. To
make that not cause more memory consumption, reduce the size of
the allocations to the necessary size - we go from 324 bytes in
each allocation to 60/68 on gen2 depending on family, and ~120
or so on gen1 (so on gen1 it's a pure reduction in size, since
we don't need alignment there).

To avoid size and clearing issues, add a new structure that's
just the header, and use kmem_cache_zalloc().
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      a89c72ff
    • J
      iwlwifi: pcie: detect the DMA bug and warn if it happens · c5a4e8eb
      由 Johannes Berg 提交于 
      Warn if the DMA bug is going to happen. We don't have a good
way of actually aborting in this case and we have workarounds
in place for the cases where it happens, but in order to not
be surprised add a safety-check and warn.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c5a4e8eb
    • J
      iwlwifi: pcie: work around DMA hardware bug · c4a786b3
      由 Johannes Berg 提交于 
      There's a hardware bug in the flow handler (DMA engine), if the
address + len of some TB wraps around a 2^32 boundary, the carry
bit is then carried over into the next TB.

Work around this by copying the data to a new page when we find
this situation, and then copy it in a way that we cannot hit the
very end of the page.

To be able to free the new page again later we need to chain it
to the TSO page, use the last pointer there to make sure we can
never use the page fully for DMA, and thus cannot cause the same
overflow situation on this page.

This leaves a few potential places (where we didn't observe the
problem) unaddressed:
 * The second TB could reach or cross the end of a page (and thus
   2^32) due to the way we allocate the dev_cmd for the header
 * For host commands, a similar thing could happen since they're
   just kmalloc().
We'll address these in further commits.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      c4a786b3
  3. 20 12月, 2019 2 次提交
  5. 19 12月, 2019 3 次提交
    • W
      libertas: Fix two buffer overflows at parsing bss descriptor · e5e884b4
      由 Wen Huang 提交于 
      add_ie_rates() copys rates without checking the length
in bss descriptor from remote AP.when victim connects to
remote attacker, this may trigger buffer overflow.
lbs_ibss_join_existing() copys rates without checking the length
in bss descriptor from remote IBSS node.when victim connects to
remote attacker, this may trigger buffer overflow.
Fix them by putting the length check before performing copy.

This fix addresses CVE-2019-14896 and CVE-2019-14897.
This also fix build warning of mixed declarations and code.
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NWen Huang <huangwenabc@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      e5e884b4
    • D
      mt76: Off by one in mt76_calc_rx_airtime() · b43e36d7
      由 Dan Carpenter 提交于 
      The sband->bitrates[] array has "sband->n_bitrates" elements so this
check needs to be >= instead of > or we could read beyond the end of the
array.

These values come from when we call mt76_register_device():

	ret = mt76_register_device(&dev->mt76, true, mt7603_rates,
				   ARRAY_SIZE(mt7603_rates));

Here sband->bitrates[] is mt7603_rates[] and ->n_bitrates is the
ARRAY_SIZE()

Fixes: 5ce09c1a ("mt76: track rx airtime for airtime fairness and survey")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b43e36d7
    • A
      mt76: fix LED link time failure · d68f4e43
      由 Arnd Bergmann 提交于 
      The mt76_led_cleanup() function is called unconditionally, which
leads to a link error when CONFIG_LEDS is a loadable module or
disabled but mt76 is built-in:

drivers/net/wireless/mediatek/mt76/mac80211.o: In function `mt76_unregister_device':
mac80211.c:(.text+0x2ac): undefined reference to `led_classdev_unregister'

Use the same trick that is guarding the registration, using an
IS_ENABLED() check for the CONFIG_MT76_LEDS symbol that indicates
whether LEDs can be used or not.

Fixes: 36f7e2b2 ("mt76: do not use devm API for led classdev")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NFelix Fietkau <nbd@nbd.name>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      d68f4e43
  7. 13 12月, 2019 1 次提交
    • T
      mac80211: Turn AQL into an NL80211_EXT_FEATURE · 911bde0f
      由 Toke Høiland-Jørgensen 提交于 
      Instead of just having an airtime flag in debugfs, turn AQL into a proper
NL80211_EXT_FEATURE, so drivers can turn it on when they are ready, and so
we also expose the presence of the feature to userspace.

This also has the effect of flipping the default, so drivers have to opt in
to using AQL instead of getting it by default with TXQs. To keep
functionality the same as pre-patch, we set this feature for ath10k (which
is where it is needed the most).

While we're at it, split out the debugfs interface so AQL gets its own
per-station debugfs file instead of using the 'airtime' file.

[Johannes:]
This effectively disables AQL for iwlwifi, where it fixes a number of
issues:
 * TSO in iwlwifi is causing underflows and associated warnings in AQL
 * HE (802.11ax) rates aren't reported properly so at HE rates, AQL could
   never have a valid estimate (it'd use 6 Mbps instead of up to 2400!)
Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191212111437.224294-1-toke@redhat.com
Fixes: 3ace10f5 ("mac80211: Implement Airtime-based Queue Limit (AQL)")
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      911bde0f
  9. 10 12月, 2019 2 次提交
  11. 02 12月, 2019 2 次提交
  13. 28 11月, 2019 3 次提交
  15. 22 11月, 2019 3 次提交
  17. 20 11月, 2019 16 次提交