Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 4月, 2020 1 次提交
  3. 21 4月, 2020 1 次提交
  5. 23 12月, 2019 5 次提交
    • J
      iwlwifi: pcie: validate queue ID before array deref/bit ops · 0e002708
      由 Johannes Berg 提交于 
      Validate that the queue ID is in range before trying to use it as
an index or for test_bit() - the previous bug showed that this has
in fact happened, and it was lucky that we caught it there, had the
bit been set then we'd have actually used the value despite being
far out of range.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      0e002708
    • 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
    • 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
  7. 20 12月, 2019 1 次提交
  9. 20 11月, 2019 2 次提交
  11. 15 11月, 2019 2 次提交
  13. 09 11月, 2019 1 次提交
  15. 06 9月, 2019 5 次提交
  17. 20 8月, 2019 1 次提交
  19. 22 3月, 2019 1 次提交
  21. 04 2月, 2019 1 次提交
  23. 29 1月, 2019 2 次提交
  25. 26 1月, 2019 2 次提交
  27. 20 12月, 2018 1 次提交
  29. 14 12月, 2018 1 次提交
  31. 11 11月, 2018 1 次提交
  33. 08 10月, 2018 2 次提交
  35. 06 10月, 2018 1 次提交
  37. 28 9月, 2018 2 次提交
  39. 31 8月, 2018 3 次提交
  41. 02 8月, 2018 2 次提交
  43. 26 7月, 2018 2 次提交