5.4-stable patches

added patches:
	arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch

diff --git a/queue-5.4/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch b/queue-5.4/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch
new file mode 100644 (file)
index 0000000..3f61d21
--- /dev/null
+++ b/queue-5.4/arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch
@@ -0,0 +1,56 @@
+From c50f11c6196f45c92ca48b16a5071615d4ae0572 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Fri, 10 Jun 2022 16:12:27 +0100
+Subject: arm64: mm: Don't invalidate FROM_DEVICE buffers at start of DMA transfer
+
+From: Will Deacon <will@kernel.org>
+
+commit c50f11c6196f45c92ca48b16a5071615d4ae0572 upstream.
+
+Invalidating the buffer memory in arch_sync_dma_for_device() for
+FROM_DEVICE transfers
+
+When using the streaming DMA API to map a buffer prior to inbound
+non-coherent DMA (i.e. DMA_FROM_DEVICE), we invalidate any dirty CPU
+cachelines so that they will not be written back during the transfer and
+corrupt the buffer contents written by the DMA. This, however, poses two
+potential problems:
+
+  (1) If the DMA transfer does not write to every byte in the buffer,
+      then the unwritten bytes will contain stale data once the transfer
+      has completed.
+
+  (2) If the buffer has a virtual alias in userspace, then stale data
+      may be visible via this alias during the period between performing
+      the cache invalidation and the DMA writes landing in memory.
+
+Address both of these issues by cleaning (aka writing-back) the dirty
+lines in arch_sync_dma_for_device(DMA_FROM_DEVICE) instead of discarding
+them using invalidation.
+
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: Russell King <linux@armlinux.org.uk>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220606152150.GA31568@willie-the-truck
+Signed-off-by: Will Deacon <will@kernel.org>
+Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20220610151228.4562-2-will@kernel.org
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/mm/cache.S |    2 --
+ 1 file changed, 2 deletions(-)
+
+--- a/arch/arm64/mm/cache.S
++++ b/arch/arm64/mm/cache.S
+@@ -228,8 +228,6 @@ ENDPIPROC(__dma_flush_area)
+  *    - dir   - DMA direction
+  */
+ ENTRY(__dma_map_area)
+-      cmp     w2, #DMA_FROM_DEVICE
+-      b.eq    __dma_inv_area
+       b       __dma_clean_area
+ ENDPIPROC(__dma_map_area)
+ 

diff --git a/queue-5.4/series b/queue-5.4/series
index ef6832b3dfcc9ddaf6bfd6a18cc2dde72535c689..0a09b9313bb78245253f2c29ccc34fa4f61c901e 100644 (file)
--- a/queue-5.4/series
+++ b/queue-5.4/series
@@ -7,3 +7,4 @@ tcp-add-small-random-increments-to-the-source-port.patch
 tcp-dynamically-allocate-the-perturb-table-used-by-source-ports.patch
 tcp-increase-source-port-perturb-table-to-2-16.patch
 tcp-drop-the-hash_32-part-from-the-index-calculation.patch
+arm64-mm-don-t-invalidate-from_device-buffers-at-start-of-dma-transfer.patch