Until VM_DONTEXPAND was added in commit 1c1914d6e8 ("dma-buf: heaps:
Don't track CMA dma-buf pages under RssFile") it was possible to obtain
a mapping larger than the buffer size via mremap and bypass the overflow
check in dma_buf_mmap_internal. When using such a mapping to attempt to
fault past the end of the buffer, the CMA heap fault handler also checks
the fault offset against the buffer size, but gets the boundary wrong by
1. Fix the boundary check so that we don't read off the end of the pages
array and insert an arbitrary page in the mapping.
Reported-by: Xingyu Jin <xingyuj@google.com>
Fixes: a5d2d29e24 ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation")
Cc: stable@vger.kernel.org # Applicable >= 5.10. Needs adjustments only for 5.10.
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Acked-by: John Stultz <jstultz@google.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240830192627.2546033-1-tjmercier@google.com
Commit 7296f2301a ("swiotlb: reduce swiotlb pool lookups") turned down
the call to is_swiotlb_buffer() in favour of a new way to interact with
swiotlb pools. Our out-of-tree use-case is trivial since we can simply
use the drop-in replacement swiotlb_find_pool().
Fixes: 7296f2301a ("swiotlb: reduce swiotlb pool lookups")
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I85bd60ff671ec178be90907a1f2201e8121bd7fd
Commit b9578c4945 ("dma-buf/heaps: Correct the types of fd_flags and
heap_flags") changed the expected types of a bunch of 'allocate' related
function calls. In order to avoid build failures, we need to follow
them.
Fixes the following build errors:
...unsigned long, unsigned int, unsigned long long)') with an expression of type
'struct dma_buf *(struct dma_heap *, unsigned long, unsigned long, unsigned long)' [-Wincompatible-function-pointer-types]
520 | .allocate = system_uncached_heap_not_initialized,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...*)(struct dma_heap *, unsigned long, unsigned int, unsigned long long)') from
'struct dma_buf *(struct dma_heap *, unsigned long, unsigned long, unsigned long)' [-Wincompatible-function-pointer-types]
545 | system_uncached_heap_ops.allocate = system_uncached_heap_allocate;
Fixes: b9578c4945 ("dma-buf/heaps: Correct the types of fd_flags and heap_flags")
Change-Id: Ic349064cc67e20dcd97a58995cdee010508e8f0e
Signed-off-by: Lee Jones <joneslee@google.com>
Uncached system heap buffers skip dma_sync_sgtable_for_*, but those
calls are required even for uncached buffers when a SWIOTLB bounce
buffer is involved. Since SWIOTLB copies greatly reduce the performance
of uncached dma-bufers, reject maps for devices which require them.
Test: Force SWIOTLB in mali_kbase on Pixel 6 which provides no
Test: dma_map_ops with: dev->dma_io_tlb_mem->force_bounce = true;
Fixes: 560ecde1b0 ("FROMLIST: dma-buf: system_heap: Add a system-uncached heap re-using the system heap")
Bug: 289327060
Change-Id: I11a62c62cd684c8cb517fd96014b8110c37fd12b
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Steps on the way to 6.6-rc1
Resolves merge conflict in:
drivers/dma-buf/heaps/system_heap.c
Change-Id: I48f2f1ef6f3caa51f220705c3c53be266e0dcefc
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Don't assert held dma-buf reservation lock on memory mapping of exported
buffer.
We're going to change dma-buf mmap() locking policy such that exporters
will have to handle the lock. The previous locking policy caused deadlock
problem for DRM drivers in a case of self-imported dma-bufs once these
drivers are moved to use reservation lock universally. The problem
solved by moving the lock down to exporters. This patch prepares dma-buf
heaps for the locking policy update.
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230529223935.2672495-3-dmitry.osipenko@collabora.com
Steps on the way to 6.4-rc1
Resolves merge conflicts in:
fs/proc/base.c
Change-Id: I05b411a5197274a765bf9d3b2fa06c8885d99bcd
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Pull MM updates from Andrew Morton:
- Nick Piggin's "shoot lazy tlbs" series, to improve the peformance of
switching from a user process to a kernel thread.
- More folio conversions from Kefeng Wang, Zhang Peng and Pankaj
Raghav.
- zsmalloc performance improvements from Sergey Senozhatsky.
- Yue Zhao has found and fixed some data race issues around the
alteration of memcg userspace tunables.
- VFS rationalizations from Christoph Hellwig:
- removal of most of the callers of write_one_page()
- make __filemap_get_folio()'s return value more useful
- Luis Chamberlain has changed tmpfs so it no longer requires swap
backing. Use `mount -o noswap'.
- Qi Zheng has made the slab shrinkers operate locklessly, providing
some scalability benefits.
- Keith Busch has improved dmapool's performance, making part of its
operations O(1) rather than O(n).
- Peter Xu adds the UFFD_FEATURE_WP_UNPOPULATED feature to userfaultd,
permitting userspace to wr-protect anon memory unpopulated ptes.
- Kirill Shutemov has changed MAX_ORDER's meaning to be inclusive
rather than exclusive, and has fixed a bunch of errors which were
caused by its unintuitive meaning.
- Axel Rasmussen give userfaultfd the UFFDIO_CONTINUE_MODE_WP feature,
which causes minor faults to install a write-protected pte.
- Vlastimil Babka has done some maintenance work on vma_merge():
cleanups to the kernel code and improvements to our userspace test
harness.
- Cleanups to do_fault_around() by Lorenzo Stoakes.
- Mike Rapoport has moved a lot of initialization code out of various
mm/ files and into mm/mm_init.c.
- Lorenzo Stoakes removd vmf_insert_mixed_prot(), which was added for
DRM, but DRM doesn't use it any more.
- Lorenzo has also coverted read_kcore() and vread() to use iterators
and has thereby removed the use of bounce buffers in some cases.
- Lorenzo has also contributed further cleanups of vma_merge().
- Chaitanya Prakash provides some fixes to the mmap selftesting code.
- Matthew Wilcox changes xfs and afs so they no longer take sleeping
locks in ->map_page(), a step towards RCUification of pagefaults.
- Suren Baghdasaryan has improved mmap_lock scalability by switching to
per-VMA locking.
- Frederic Weisbecker has reworked the percpu cache draining so that it
no longer causes latency glitches on cpu isolated workloads.
- Mike Rapoport cleans up and corrects the ARCH_FORCE_MAX_ORDER Kconfig
logic.
- Liu Shixin has changed zswap's initialization so we no longer waste a
chunk of memory if zswap is not being used.
- Yosry Ahmed has improved the performance of memcg statistics
flushing.
- David Stevens has fixed several issues involving khugepaged,
userfaultfd and shmem.
- Christoph Hellwig has provided some cleanup work to zram's IO-related
code paths.
- David Hildenbrand has fixed up some issues in the selftest code's
testing of our pte state changing.
- Pankaj Raghav has made page_endio() unneeded and has removed it.
- Peter Xu contributed some rationalizations of the userfaultfd
selftests.
- Yosry Ahmed has fixed an issue around memcg's page recalim
accounting.
- Chaitanya Prakash has fixed some arm-related issues in the
selftests/mm code.
- Longlong Xia has improved the way in which KSM handles hwpoisoned
pages.
- Peter Xu fixes a few issues with uffd-wp at fork() time.
- Stefan Roesch has changed KSM so that it may now be used on a
per-process and per-cgroup basis.
* tag 'mm-stable-2023-04-27-15-30' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (369 commits)
mm,unmap: avoid flushing TLB in batch if PTE is inaccessible
shmem: restrict noswap option to initial user namespace
mm/khugepaged: fix conflicting mods to collapse_file()
sparse: remove unnecessary 0 values from rc
mm: move 'mmap_min_addr' logic from callers into vm_unmapped_area()
hugetlb: pte_alloc_huge() to replace huge pte_alloc_map()
maple_tree: fix allocation in mas_sparse_area()
mm: do not increment pgfault stats when page fault handler retries
zsmalloc: allow only one active pool compaction context
selftests/mm: add new selftests for KSM
mm: add new KSM process and sysfs knobs
mm: add new api to enable ksm per process
mm: shrinkers: fix debugfs file permissions
mm: don't check VMA write permissions if the PTE/PMD indicates write permissions
migrate_pages_batch: fix statistics for longterm pin retry
userfaultfd: use helper function range_in_vma()
lib/show_mem.c: use for_each_populated_zone() simplify code
mm: correct arg in reclaim_pages()/reclaim_clean_pages_from_list()
fs/buffer: convert create_page_buffers to folio_create_buffers
fs/buffer: add folio_create_empty_buffers helper
...
Using order 4 pages would be helpful for IOMMUs mapping, but trying to get
order 4 pages could spend quite much time in the page allocation. From
the perspective of responsiveness, the deterministic memory allocation
speed, I think, is quite important.
The order 4 allocation with __GFP_RECLAIM may spend much time in reclaim
and compation logic. __GFP_NORETRY also may affect. These cause
unpredictable delay.
To get reasonable allocation speed from dma-buf system heap, use
HIGH_ORDER_GFP for order 4 to avoid reclaim. And let me remove
meaningless __GFP_COMP for order 0.
According to my tests, order 4 with MID_ORDER_GFP could get more number
of order 4 pages but the elapsed times could be very slow.
time order 8 order 4 order 0
584 usec 0 160 0
28,428 usec 0 160 0
100,701 usec 0 160 0
76,645 usec 0 160 0
25,522 usec 0 160 0
38,798 usec 0 160 0
89,012 usec 0 160 0
23,015 usec 0 160 0
73,360 usec 0 160 0
76,953 usec 0 160 0
31,492 usec 0 160 0
75,889 usec 0 160 0
84,551 usec 0 160 0
84,352 usec 0 160 0
57,103 usec 0 160 0
93,452 usec 0 160 0
If HIGH_ORDER_GFP is used for order 4, the number of order 4 could be
decreased but the elapsed time results were quite stable and fast enough.
time order 8 order 4 order 0
1,356 usec 0 155 80
1,901 usec 0 11 2384
1,912 usec 0 0 2560
1,911 usec 0 0 2560
1,884 usec 0 0 2560
1,577 usec 0 0 2560
1,366 usec 0 0 2560
1,711 usec 0 0 2560
1,635 usec 0 28 2112
544 usec 10 0 0
633 usec 2 128 0
848 usec 0 160 0
729 usec 0 160 0
1,000 usec 0 160 0
1,358 usec 0 160 0
2,638 usec 0 31 2064
Link: https://lkml.kernel.org/r/20230303050332.10138-1-jaewon31.kim@samsung.com
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Reviewed-by: John Stultz <jstultz@google.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Steps on the way to 6.2-rc1
Resolves merge conflicts in:
drivers/dma-buf/dma-buf.c
drivers/dma-buf/heaps/system_heap.c
include/linux/dma-buf.h
Change-Id: I0b65680a68e10f3da6e510b8e4f58fcaff625fdf
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
For dma-heap users, they can't bypass cache sync when map/unmap iova
with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC
into dma_alloc_attrs.
To keep alignment, at dma_heap side, also use
dma_buf_attachment.dma_map_attrs to do iova map & unmap.
This patch is a little different with linux patch, because ACK
has cached heap, and linux doesn't have it
Bug: 229794062
Link: https://lore.kernel.org/patchwork/patch/1455032/
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
(cherry picked from commit 9d3a91652bb1a762312051fdbb403cd5dec58e05)
Change-Id: Idbd96c8486ad752d88d93b204daaefc605261845
For dma-heap users, they can't bypass cache sync when map/unmap iova
with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC
into dma_alloc_attrs.
To keep alignment, at dma_heap side, also use
dma_buf_attachment.dma_map_attrs to do iova map & unmap.
This patch is a little different with linux patch, because ACK
has cached heap, and linux doesn't have it
Bug: 229794062
Link: https://lore.kernel.org/patchwork/patch/1455032/
Change-Id: I324712644688c29e55c9197efcde9283bbbd813b
Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com>
(cherry picked from commit 9d3a91652bb1a762312051fdbb403cd5dec58e05)
Steps on the way to 5.18-rc1
Resolves merge conflicts in:
include/linux/dma-buf.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iac98a19746b56875a98835afe2c46c6646763399
Rename struct dma_buf_map to struct iosys_map and corresponding APIs.
Over time dma-buf-map grew up to more functionality than the one used by
dma-buf: in fact it's just a shim layer to abstract system memory, that
can be accessed via regular load and store, from IO memory that needs to
be acessed via arch helpers.
The idea is to extend this API so it can fulfill other needs, internal
to a single driver. Example: in the i915 driver it's desired to share
the implementation for integrated graphics, which uses mostly system
memory, with discrete graphics, which may need to access IO memory.
The conversion was mostly done with the following semantic patch:
@r1@
@@
- struct dma_buf_map
+ struct iosys_map
@r2@
@@
(
- DMA_BUF_MAP_INIT_VADDR
+ IOSYS_MAP_INIT_VADDR
|
- dma_buf_map_set_vaddr
+ iosys_map_set_vaddr
|
- dma_buf_map_set_vaddr_iomem
+ iosys_map_set_vaddr_iomem
|
- dma_buf_map_is_equal
+ iosys_map_is_equal
|
- dma_buf_map_is_null
+ iosys_map_is_null
|
- dma_buf_map_is_set
+ iosys_map_is_set
|
- dma_buf_map_clear
+ iosys_map_clear
|
- dma_buf_map_memcpy_to
+ iosys_map_memcpy_to
|
- dma_buf_map_incr
+ iosys_map_incr
)
@@
@@
- #include <linux/dma-buf-map.h>
+ #include <linux/iosys-map.h>
Then some files had their includes adjusted and some comments were
update to remove mentions to dma-buf-map.
Since this is not specific to dma-buf anymore, move the documentation to
the "Bus-Independent Device Accesses" section.
v2:
- Squash patches
v3:
- Fix wrong removal of dma-buf.h from MAINTAINERS
- Move documentation from dma-buf.rst to device-io.rst
v4:
- Change documentation title and level
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204170541.829227-1-lucas.demarchi@intel.com
For previous version, it uses 'sg_table.nent's to traverse sg_table in pages
free flow.
However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of
created entries in the DMA adderess space.
So, use 'sg_table.nents' in pages free flow will case some pages can't be freed.
Here we should use sg_table.orig_nents to free pages memory, but use the
sgtable helper 'for each_sgtable_sg'(, instead of the previous rather common
helper 'for_each_sg' which maybe cause memory leak) is much better.
Fixes: d963ab0f15 ("dma-buf: system_heap: Allocate higher order pages if available")
Signed-off-by: Guangming <Guangming.Cao@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Cc: <stable@vger.kernel.org> # 5.11.*
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211126074904.88388-1-guangming.cao@mediatek.com
Commit 16b0314aa7 ("dma-buf: move dma-buf symbols into the DMA_BUF
module namespace") moved the dma-buf exports into the DMA_BUF namespace.
To keep the system_heap.c and cma_heap modules building, add them to the
DMA_BUF namespace as well.
Fixes: 16b0314aa7 ("dma-buf: move dma-buf symbols into the DMA_BUF module namespace")
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib69062d41c426844f82667a51d75f0c35bad2bdf
Steps on the way to 5.12-rc1
Resolves merge conflicts in:
drivers/dma-buf/dma-heap.c
drivers/dma-buf/heaps/cma_heap.c
drivers/dma-buf/heaps/system_heap.c
include/linux/dma-heap.h
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibb32dbdba5183c9e19f5d1e94016cc1ae9616173
This patch sets CONFIG_DMABUF_HEAPS_SYSTEM to tristate and exports the
symbol dma_heap_get_dev() to allow the DMA-BUF system heap to be a
module.
This change is intended to allow partners to continue using
device/SoC-specific optimizations in their system heap implementations
when they switch from ION to DMA-BUF heaps. The ION system heap was
built-in and partners were asked to override the system heap ID with
their own if they wanted to override the GKI system heap. This
per-vendor approach to override system heap will no longer be possible
with DMA-BUF heaps since Android S aims to restrict framework access to
DMA-BUF vendor heaps by only letting it access ABI-defined vendor heaps.
VTS tests will be created to ensure that the system heap is present
at /dev/dma_heap/system and behaves as expected of the system heap.
Bug: 175697666
Bug: 155218010
Bug: 172527615
Change-Id: Iabb24d9aedde308a9b15509781dd0e6b67353e99
Signed-off-by: Hridya Valsaraju <hridya@google.com>
(cherry picked from commit c975699b4953ea3251695c16ef65ecb722c91188)
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
This adds a heap that allocates non-contiguous buffers that are
marked as writecombined, so they are not cached by the CPU.
This is useful, as most graphics buffers are usually not touched
by the CPU or only written into once by the CPU. So when mapping
the buffer over and over between devices, we can skip the CPU
syncing, which saves a lot of cache management overhead, greatly
improving performance.
For folk using ION, there was a ION_FLAG_CACHED flag, which
signaled if the returned buffer should be CPU cacheable or not.
With DMA-BUF heaps, we do not yet have such a flag, and by default
the current heaps (system and cma) produce CPU cachable buffers.
So for folks transitioning from ION to DMA-BUF Heaps, this fills
in some of that missing functionality.
There has been a suggestion to make this functionality a flag
(DMAHEAP_FLAG_UNCACHED?) on the system heap, similar to how
ION used the ION_FLAG_CACHED. But I want to make sure an
_UNCACHED flag would truely be a generic attribute across all
heaps. So far that has been unclear, so having it as a separate
heap seemes better for now. (But I'm open to discussion on this
point!)
This is a rework of earlier efforts to add a uncached system heap,
done utilizing the exisitng system heap, adding just a bit of
logic to handle the uncached case.
Feedback would be very welcome!
Many thanks to Liam Mark for his help to get this working.
Pending opensource users of this code include:
* AOSP HiKey960 gralloc:
- https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
- Visibly improves performance over the system heap
* AOSP Codec2 (possibly, needs more review):
- https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
Signed-off-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/lkml/20201110034934.70898-8-john.stultz@linaro.org/
Bug: 170887642
Change-Id: I56cb3acf58546c7dfd423a2ce432e3d6d7fd7a69
Signed-off-by: Hridya Valsaraju <hridya@google.com>
(cherry picked from commit 79793050fa3eaad4099e259a63622ffea17f0683)
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Steps on the way to 5.11-rc1
Resolves merge issues in:
kernel/sched/sched.h
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: If5b00273202785ed39c5f46dfb92dd7791499cda
Steps on the way to 5.11-rc1
Resolves conflicts in:
drivers/dma-buf/heaps/cma_heap.c
drivers/dma-buf/heaps/system_heap.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iac498252911dd67ee21bba42b3fa5a2324dd43e0
Because of 20e76f1a70 ("dma-buf: Use struct dma_buf_map in
dma_buf_vunmap() interfaces") and 6619ccf1bb ("dma-buf: Use struct
dma_buf_map in dma_buf_vmap() interfaces"), the vmap and vunmap callback
functions changed. Fix up the cma_heap.c code to reflect these changes.
Fixes: b61614ec31 ("dma-buf: heaps: Add CMA heap to dmabuf heaps")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I14e8d404a945db3b63f78a811f23928ecb316c2c
Steps on the way to 5.11-rc1.
Required resolutions in:
include/linux/dma-buf.h
drivers/dma-buf/heaps/system_heap.c
drivers/staging/android/ion/ion_dma_buf.c
drivers/dma-buf/heaps/heap-helpers.c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ic546af62c7f61b5c754ece178c32f45878013c3a
This patch is basically a port of Ørjan Eide's similar patch for ION
https://lore.kernel.org/lkml/20200414134629.54567-1-orjan.eide@arm.com/
Only sync the sg-list of dma-buf heap attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Before v5.0 (commit 55897af630 ("dma-direct: merge swiotlb_dma_ops
into the dma_direct code")) this was a problem as the dma-api (at least
the swiotlb_dma_ops on arm64) would use the potentially invalid
dma_address. How that failed depended on how the device handled physical
address 0. If 0 was a valid address to physical ram, that page would get
flushed a lot, while the actual pages in the buffer would not get synced
correctly. While if 0 is an invalid physical address it may cause a
fault and trigger a crash.
In v5.0 this was incidentally fixed by commit 55897af630 ("dma-direct:
merge swiotlb_dma_ops into the dma_direct code"), as this moved the
dma-api to use the page pointer in the sg_list, and (for Ion buffers at
least) this will always be valid if the sg_list exists at all.
But, this issue is re-introduced in v5.3 with
commit 449fa54d68 ("dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device") moves the dma-api back to the old
behaviour and picks the dma_address that may be invalid.
dma-buf core doesn't ensure that the buffer is mapped on the device, and
thus have a valid sg_list, before calling the exporter's
begin_cpu_access.
Logic and commit message originally by: Ørjan Eide <orjan.eide@arm.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Liam Mark <lmark@codeaurora.org>
Cc: Laura Abbott <labbott@kernel.org>
Cc: Brian Starkey <Brian.Starkey@arm.com>
Cc: Hridya Valsaraju <hridya@google.com>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Sandeep Patil <sspatil@google.com>
Cc: Daniel Mentz <danielmentz@google.com>
Cc: Chris Goldsworthy <cgoldswo@codeaurora.org>
Cc: Ørjan Eide <orjan.eide@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: James Jones <jajones@nvidia.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Bug: 173440990
(cherry picked from commit 4c68e499bb
git: //anongit.freedesktop.org/drm/drm-misc
tags/drm-misc-next-2020-11-27)
Link: https://lore.kernel.org/patchwork/patch/1343071/
Change-Id: If1c7312e437a8166a7d3e65bcd4c352f46cab718
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Hridya Valsaraju <hridya@google.com>
Greg Kroah-Hartman
T.J. Mercier
Lee Jones
Barry Song
Dmitry Osipenko
Linus Torvalds
Nick Alcock
Jaewon Kim
Guangming Cao
Lucas De Marchi
Weizhao Ouyang
John Stultz
Dave Airlie
Hridya Valsaraju