Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 4月, 2020 1 次提交
    • D
      dma-pool: add additional coherent pools to map to gfp mask · c84dc6e6
      由 David Rientjes 提交于 
      The single atomic pool is allocated from the lowest zone possible since
it is guaranteed to be applicable for any DMA allocation.

Devices may allocate through the DMA API but not have a strict reliance
on GFP_DMA memory.  Since the atomic pool will be used for all
non-blockable allocations, returning all memory from ZONE_DMA may
unnecessarily deplete the zone.

Provision for multiple atomic pools that will map to the optimal gfp
mask of the device.

When allocating non-blockable memory, determine the optimal gfp mask of
the device and use the appropriate atomic pool.

The coherent DMA mask will remain the same between allocation and free
and, thus, memory will be freed to the same atomic pool it was allocated
from.

__dma_atomic_pool_init() will be changed to return struct gen_pool *
later once dynamic expansion is added.
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      c84dc6e6
  3. 04 3月, 2020 1 次提交
    • M
      iommu/dma: Fix MSI reservation allocation · 65ac74f1
      由 Marc Zyngier 提交于 
      The way cookie_init_hw_msi_region() allocates the iommu_dma_msi_page
structures doesn't match the way iommu_put_dma_cookie() frees them.

The former performs a single allocation of all the required structures,
while the latter tries to free them one at a time. It doesn't quite
work for the main use case (the GICv3 ITS where the range is 64kB)
when the base granule size is 4kB.

This leads to a nice slab corruption on teardown, which is easily
observable by simply creating a VF on a SRIOV-capable device, and
tearing it down immediately (no need to even make use of it).
Fortunately, this only affects systems where the ITS isn't translated
by the SMMU, which are both rare and non-standard.

Fix it by allocating iommu_dma_msi_page structures one at a time.

Fixes: 7c1b058c ("iommu/dma: Handle IOMMU API reserved regions")
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Joerg Roedel <jroedel@suse.de>
Cc: Will Deacon <will@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      65ac74f1
  5. 08 1月, 2020 1 次提交
  7. 19 12月, 2019 1 次提交
  9. 17 12月, 2019 1 次提交
  11. 22 11月, 2019 1 次提交
    • N
      dma-mapping: treat dev->bus_dma_mask as a DMA limit · a7ba70f1
      由 Nicolas Saenz Julienne 提交于 
      Using a mask to represent bus DMA constraints has a set of limitations.
The biggest one being it can only hold a power of two (minus one). The
DMA mapping code is already aware of this and treats dev->bus_dma_mask
as a limit. This quirk is already used by some architectures although
still rare.

With the introduction of the Raspberry Pi 4 we've found a new contender
for the use of bus DMA limits, as its PCIe bus can only address the
lower 3GB of memory (of a total of 4GB). This is impossible to represent
with a mask. To make things worse the device-tree code rounds non power
of two bus DMA limits to the next power of two, which is unacceptable in
this case.

In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all
over the tree and treat it as such. Note that dev->bus_dma_limit should
contain the higher accessible DMA address.
Signed-off-by: NNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
      a7ba70f1
  13. 21 11月, 2019 1 次提交
  15. 15 10月, 2019 3 次提交
  17. 04 9月, 2019 2 次提交
  19. 03 9月, 2019 1 次提交
  21. 30 8月, 2019 1 次提交
  23. 21 8月, 2019 1 次提交
  25. 11 8月, 2019 1 次提交
    • C
      dma-mapping: fix page attributes for dma_mmap_* · 33dcb37c
      由 Christoph Hellwig 提交于 
      All the way back to introducing dma_common_mmap we've defaulted to mark
the pages as uncached.  But this is wrong for DMA coherent devices.
Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
flag is only treated special on the alloc side for non-coherent devices.

Introduce a new dma_pgprot helper that deals with the check for coherent
devices so that only the remapping cases ever reach arch_dma_mmap_pgprot
and we thus ensure no aliasing of page attributes happens, which makes
the powerpc version of arch_dma_mmap_pgprot obsolete and simplifies the
remaining ones.

Note that this means arch_dma_mmap_pgprot is a bit misnamed now, but
we'll phase it out soon.

Fixes: 64ccc9c0 ("common: dma-mapping: add support for generic dma_mmap_* calls")
Reported-by: NShawn Anastasio <shawn@anastas.io>
Reported-by: NGavin Li <git@thegavinli.com>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> # arm64
      33dcb37c
  27. 09 8月, 2019 1 次提交
    • R
      iommu/dma: Handle SG length overflow better · ab2cbeb0
      由 Robin Murphy 提交于 
      Since scatterlist dimensions are all unsigned ints, in the relatively
rare cases where a device's max_segment_size is set to UINT_MAX, then
the "cur_len + s_length <= max_len" check in __finalise_sg() will always
return true. As a result, the corner case of such a device mapping an
excessively large scatterlist which is mergeable to or beyond a total
length of 4GB can lead to overflow and a bogus truncated dma_length in
the resulting segment.

As we already assume that any single segment must be no longer than
max_len to begin with, this can easily be addressed by reshuffling the
comparison.

Fixes: 809eac54 ("iommu/dma: Implement scatterlist segment merging")
Reported-by: NNicolin Chen <nicoleotsuka@gmail.com>
Tested-by: NNicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      ab2cbeb0
  29. 06 8月, 2019 1 次提交
  31. 24 7月, 2019 1 次提交
    • W
      iommu: Introduce struct iommu_iotlb_gather for batching TLB flushes · a7d20dc1
      由 Will Deacon 提交于 
      To permit batching of TLB flushes across multiple calls to the IOMMU
driver's ->unmap() implementation, introduce a new structure for
tracking the address range to be flushed and the granularity at which
the flushing is required.

This is hooked into the IOMMU API and its caller are updated to make use
of the new structure. Subsequent patches will plumb this into the IOMMU
drivers as well, but for now the gathering information is ignored.
Signed-off-by: NWill Deacon <will@kernel.org>
      a7d20dc1
  33. 19 6月, 2019 1 次提交
  35. 18 6月, 2019 1 次提交
    • A
      iommu: Fix integer truncation · 29fcea8c
      由 Arnd Bergmann 提交于 
      On 32-bit architectures, phys_addr_t may be different from dma_add_t,
both smaller and bigger. This can lead to an overflow during an assignment
that clang warns about:

drivers/iommu/dma-iommu.c:230:10: error: implicit conversion from 'dma_addr_t' (aka 'unsigned long long') to
      'phys_addr_t' (aka 'unsigned int') changes value from 18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion]

Use phys_addr_t here because that is the type that the variable was
declared as.

Fixes: aadad097 ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      29fcea8c
  37. 14 6月, 2019 1 次提交
  39. 03 6月, 2019 1 次提交
  41. 27 5月, 2019 17 次提交