Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 12月, 2020 2 次提交
  3. 09 10月, 2020 1 次提交
  5. 02 10月, 2020 6 次提交
  7. 08 8月, 2020 1 次提交
    • W
      mm, treewide: rename kzfree() to kfree_sensitive() · 453431a5
      由 Waiman Long 提交于 
      As said by Linus:

  A symmetric naming is only helpful if it implies symmetries in use.
  Otherwise it's actively misleading.

  In "kzalloc()", the z is meaningful and an important part of what the
  caller wants.

  In "kzfree()", the z is actively detrimental, because maybe in the
  future we really _might_ want to use that "memfill(0xdeadbeef)" or
  something. The "zero" part of the interface isn't even _relevant_.

The main reason that kzfree() exists is to clear sensitive information
that should not be leaked to other future users of the same memory
objects.

Rename kzfree() to kfree_sensitive() to follow the example of the recently
added kvfree_sensitive() and make the intention of the API more explicit.
In addition, memzero_explicit() is used to clear the memory to make sure
that it won't get optimized away by the compiler.

The renaming is done by using the command sequence:

  git grep -w --name-only kzfree |\
  xargs sed -i 's/kzfree/kfree_sensitive/'

followed by some editing of the kfree_sensitive() kerneldoc and adding
a kzfree backward compatibility macro in slab.h.

[akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
[akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]
Suggested-by: NJoe Perches <joe@perches.com>
Signed-off-by: NWaiman Long <longman@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NMichal Hocko <mhocko@suse.com>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Joe Perches <joe@perches.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: "Jason A . Donenfeld" <Jason@zx2c4.com>
Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.comSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      453431a5
  9. 29 5月, 2020 2 次提交
  11. 08 5月, 2020 1 次提交
  13. 27 3月, 2020 1 次提交
  15. 23 12月, 2019 3 次提交
    • L
      iwlwifi: remove CSR registers abstraction · 6dece0e9
      由 Luca Coelho 提交于 
      We needed this abstraction for some CSR registers for
IWL_DEVICE_22560, but that has been removed, so we don't need the
abstraction anymore.  Remove it.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      6dece0e9
    • 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: 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
  17. 20 12月, 2019 1 次提交
  19. 20 11月, 2019 1 次提交
  21. 15 11月, 2019 1 次提交
  23. 06 9月, 2019 7 次提交
  25. 31 7月, 2019 1 次提交
  27. 19 4月, 2019 1 次提交
  29. 03 4月, 2019 1 次提交
  31. 22 3月, 2019 1 次提交
  33. 14 2月, 2019 2 次提交
    • S
      iwlwifi: pcie: fix TX while flushing · 2ae48edc
      由 Sara Sharon 提交于 
      When flushing TX queues no new TX should go into the system.
However, in the following scenario we get TX:
1. Queues are stopped and there are packets in overflow queue
2. Station is removed and flush begins
3. Flush empties space, and reclaim path TXes SKB from overflow
   queue.

Note that the fact the queues are stopped during the process
doesn't matter - the packet will be TXed since the TX path
doesn't care if TX queues are stopped or not, just if there is
space in the queue, which there is, since we just freed a
packet.

A fix here is rather complicated, since the flow is very racy.

Change code not to warn if we are TXing from overflow TX.
In case there is TX from both overflow TX and TX path we will
miss a warning we optimally had, but we can live with that.

Make sure we don't return before overflow queue is empty, otherwise
we will think queues are empty, but they will be refilled, resulting
with assert.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Fixes: 3955525d ("iwlwifi: pcie: buffer packets to avoid overflowing Tx queues")
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      2ae48edc
    • S
      iwlwifi: introduce device family AX210 · ff911dca
      由 Shaul Triebitz 提交于 
      Add new device family AX210.
Make the needed changes for this family.
Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      ff911dca
  35. 04 2月, 2019 1 次提交
  37. 29 1月, 2019 1 次提交
    • J
      iwlwifi: pcie: align licensing to dual GPL/BSD · cefec29e
      由 Johannes Berg 提交于 
      These files have a long history of code changes, but analysing
the remaining code leads to having only a few changes that are
not already owned by Intel, notably from
 - Andy Lutomirski <luto@amacapital.net>
 - Joonwoo Park <joonwpark81@gmail.com>
 - Kirtika Ruchandani <kirtika@chromium.org>
 - Rajat Jain <rajatja@google.com>
 - Stanislaw Gruszka <sgruszka@redhat.com>
remaining in the code today.

Note that
 - I myself was working for Intel and for any possibly code
   that might be before my employment there give permission
 - Wizery employees were working for Intel

More specifically, we identified the following commits that
(partially may) remain today:

25c03d8e Joonwoo Park <joonwpark81@gmail.com>      ("iwlwifi: do not schedule tasklet when rcv unused irq")
f36d04ab Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: use dma_alloc_coherent")
387f3381 Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: fix dma mappings and skbs leak")
2624e96c Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: fix possible data overwrite in hcmd callback")
bfe4b80e Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: always check if got h/w access before write")
d536c32b Andy Lutomirski <luto@amacapital.net>     ("iwlwifi: pcie: log when waking the NIC for hcmd submission fails")
a6d24fad Rajat Jain <rajatja@google.com>           ("iwlwifi: pcie: dump registers when HW becomes inaccessible")
fb12777a Kirtika Ruchandani <kirtika@chromium.org> ("iwlwifi: Add more call-sites for pcie reg dumper")
3a73a300 Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: cleanup/fix memory barriers")
aa5affba Stanislaw Gruszka <sgruszka@redhat.com>   ("iwlwifi: dump stack when fail to gain access to the device")

Align the licenses with their permission to clean up and to
make it all identical.

CC: Joonwoo Park <joonwpark81@gmail.com>
CC: Stanislaw Gruszka <sgruszka@redhat.com>
CC: Andy Lutomirski <luto@amacapital.net>
CC: Rajat Jain <rajatja@google.com>
CC: Kirtika Ruchandani <kirtika@chromium.org>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NKirtika Ruchandani <kirtika@chromium.org>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Acked-by: NJoonwoo Park <joonwpark81@gmail.com>
Acked-by: NRajat Jain <rajatja@google.com>
Acked-by: NAndy Lutomirski <luto@kernel.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      cefec29e
  39. 26 1月, 2019 1 次提交
  41. 20 12月, 2018 1 次提交
  43. 14 12月, 2018 1 次提交
    • S
      iwlwifi: pcie: fix erroneous print · 0916224e
      由 Sara Sharon 提交于 
      When removing the driver, the following flow can happen:
1. host command is in progress, for example at index 68.
2. RX interrupt is received with the response.
3. Before it is processed, the remove flow kicks in, and
   calls iwl_pcie_txq_unmap. The function cleans all DMA,
   and promotes the read pointer to 69.
4. RX thread proceeds with the processing, and is calling
   iwl_pcie_cmdq_reclaim, which will print this error:
   iwl_pcie_cmdq_reclaim: Read index for DMA queue txq id (0),
   index 4 is out of range [0-256] 69 69.

Detect this situation, and avoid the print. Change it to
warning while at it, to make such issues more noticeable
in the future.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      0916224e
  45. 08 10月, 2018 1 次提交
  47. 06 10月, 2018 1 次提交