[gentoo-commits] proj/linux-patches:5.15 commit in: /

[Mike Pagano]

commit:     bf6c096fd2d319361768ba0d0a594cb547926550
Author:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
AuthorDate: Fri Apr  8 12:57:11 2022 +0000
Commit:     Mike Pagano <mpagano <AT> gentoo <DOT> org>
CommitDate: Fri Apr  8 12:57:11 2022 +0000
URL:        https://gitweb.gentoo.org/proj/linux-patches.git/commit/?id=bf6c096f

Remove redundant patch

Removed:
2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch

Signed-off-by: Mike Pagano <mpagano <AT> gentoo.org>

 0000_README                                        |   4 -
 ...rework-fix-info-leak-with-dma_from_device.patch | 187 ---------------------
 2 files changed, 191 deletions(-)

diff --git a/0000_README b/0000_README
index 76ca5b56..9399ac67 100644
--- a/0000_README
+++ b/0000_README
@@ -187,10 +187,6 @@ Patch:  2000_BT-Check-key-sizes-only-if-Secure-Simple-Pairing-enabled.patch
 From:   https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@××××××××.org/raw
 Desc:   Bluetooth: Check key sizes only when Secure Simple Pairing is enabled. See bug #686758
 
-Patch:  2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch
-From:   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
-Desc:   Revert swiotlb: rework fix info leak with DMA_FROM_DEVICE
-
 Patch:  2900_tmp513-Fix-build-issue-by-selecting-CONFIG_REG.patch
 From:   https://bugs.gentoo.org/710790
 Desc:   tmp513 requies REGMAP_I2C to build.  Select it by default in Kconfig. See bug #710790. Thanks to Phil Stracchino

diff --git a/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch b/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch
deleted file mode 100644
index 69476ab1..00000000
--- a/2410_revert-swiotlb-rework-fix-info-leak-with-dma_from_device.patch
+++ /dev/null
@@ -1,187 +0,0 @@
-From bddac7c1e02ba47f0570e494c9289acea3062cc1 Mon Sep 17 00:00:00 2001
-From: Linus Torvalds <torvalds@××××××××××××××××.org>
-Date: Sat, 26 Mar 2022 10:42:04 -0700
-Subject: Revert "swiotlb: rework "fix info leak with DMA_FROM_DEVICE""
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-From: Linus Torvalds <torvalds@××××××××××××××××.org>
-
-commit bddac7c1e02ba47f0570e494c9289acea3062cc1 upstream.
-
-This reverts commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13.
-
-It turns out this breaks at least the ath9k wireless driver, and
-possibly others.
-
-What the ath9k driver does on packet receive is to set up the DMA
-transfer with:
-
-  int ath_rx_init(..)
-  ..
-                bf->bf_buf_addr = dma_map_single(sc->dev, skb->data,
-                                                 common->rx_bufsize,
-                                                 DMA_FROM_DEVICE);
-
-and then the receive logic (through ath_rx_tasklet()) will fetch
-incoming packets
-
-  static bool ath_edma_get_buffers(..)
-  ..
-        dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
-                                common->rx_bufsize, DMA_FROM_DEVICE);
-
-        ret = ath9k_hw_process_rxdesc_edma(ah, rs, skb->data);
-        if (ret == -EINPROGRESS) {
-                /*let device gain the buffer again*/
-                dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
-                                common->rx_bufsize, DMA_FROM_DEVICE);
-                return false;
-        }
-
-and it's worth noting how that first DMA sync:
-
-    dma_sync_single_for_cpu(..DMA_FROM_DEVICE);
-
-is there to make sure the CPU can read the DMA buffer (possibly by
-copying it from the bounce buffer area, or by doing some cache flush).
-The iommu correctly turns that into a "copy from bounce bufer" so that
-the driver can look at the state of the packets.
-
-In the meantime, the device may continue to write to the DMA buffer, but
-we at least have a snapshot of the state due to that first DMA sync.
-
-But that _second_ DMA sync:
-
-    dma_sync_single_for_device(..DMA_FROM_DEVICE);
-
-is telling the DMA mapping that the CPU wasn't interested in the area
-because the packet wasn't there.  In the case of a DMA bounce buffer,
-that is a no-op.
-
-Note how it's not a sync for the CPU (the "for_device()" part), and it's
-not a sync for data written by the CPU (the "DMA_FROM_DEVICE" part).
-
-Or rather, it _should_ be a no-op.  That's what commit aa6f8dcbab47
-broke: it made the code bounce the buffer unconditionally, and changed
-the DMA_FROM_DEVICE to just unconditionally and illogically be
-DMA_TO_DEVICE.
-
-[ Side note: purely within the confines of the swiotlb driver it wasn't
-  entirely illogical: The reason it did that odd DMA_FROM_DEVICE ->
-  DMA_TO_DEVICE conversion thing is because inside the swiotlb driver,
-  it uses just a swiotlb_bounce() helper that doesn't care about the
-  whole distinction of who the sync is for - only which direction to
-  bounce.
-
-  So it took the "sync for device" to mean that the CPU must have been
-  the one writing, and thought it meant DMA_TO_DEVICE. ]
-
-Also note how the commentary in that commit was wrong, probably due to
-that whole confusion, claiming that the commit makes the swiotlb code
-
-                                  "bounce unconditionally (that is, also
-    when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale
-    data from the swiotlb buffer"
-
-which is nonsensical for two reasons:
-
- - that "also when dir == DMA_TO_DEVICE" is nonsensical, as that was
-   exactly when it always did - and should do - the bounce.
-
- - since this is a sync for the device (not for the CPU), we're clearly
-   fundamentally not coping back stale data from the bounce buffers at
-   all, because we'd be copying *to* the bounce buffers.
-
-So that commit was just very confused.  It confused the direction of the
-synchronization (to the device, not the cpu) with the direction of the
-DMA (from the device).
-
-Reported-and-bisected-by: Oleksandr Natalenko <oleksandr@×××××××××.name>
-Reported-by: Olha Cherevyk <olha.cherevyk@×××××.com>
-Cc: Halil Pasic <pasic@×××××××××.com>
-Cc: Christoph Hellwig <hch@×××.de>
-Cc: Kalle Valo <kvalo@××××××.org>
-Cc: Robin Murphy <robin.murphy@×××.com>
-Cc: Toke Høiland-Jørgensen <toke@××××.dk>
-Cc: Maxime Bizon <mbizon@×××××××.fr>
-Cc: Johannes Berg <johannes@××××××××××××.net>
-Signed-off-by: Linus Torvalds <torvalds@××××××××××××××××.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@×××××××××××××××.org>
----
- Documentation/core-api/dma-attributes.rst |    8 ++++++++
- include/linux/dma-mapping.h               |    8 ++++++++
- kernel/dma/swiotlb.c                      |   23 ++++++++---------------
- 3 files changed, 24 insertions(+), 15 deletions(-)
-
---- a/Documentation/core-api/dma-attributes.rst
-+++ b/Documentation/core-api/dma-attributes.rst
-@@ -130,3 +130,11 @@ accesses to DMA buffers in both privileg
- subsystem that the buffer is fully accessible at the elevated privilege
- level (and ideally inaccessible or at least read-only at the
- lesser-privileged levels).
-+
-+DMA_ATTR_OVERWRITE
-+------------------
-+
-+This is a hint to the DMA-mapping subsystem that the device is expected to
-+overwrite the entire mapped size, thus the caller does not require any of the
-+previous buffer contents to be preserved. This allows bounce-buffering
-+implementations to optimise DMA_FROM_DEVICE transfers.
---- a/include/linux/dma-mapping.h
-+++ b/include/linux/dma-mapping.h
-@@ -62,6 +62,14 @@
- #define DMA_ATTR_PRIVILEGED		(1UL << 9)
- 
- /*
-+ * This is a hint to the DMA-mapping subsystem that the device is expected
-+ * to overwrite the entire mapped size, thus the caller does not require any
-+ * of the previous buffer contents to be preserved. This allows
-+ * bounce-buffering implementations to optimise DMA_FROM_DEVICE transfers.
-+ */
-+#define DMA_ATTR_OVERWRITE		(1UL << 10)
-+
-+/*
-  * A dma_addr_t can hold any valid DMA or bus address for the platform.  It can
-  * be given to a device to use as a DMA source or target.  It is specific to a
-  * given device and there may be a translation between the CPU physical address
---- a/kernel/dma/swiotlb.c
-+++ b/kernel/dma/swiotlb.c
-@@ -627,14 +627,10 @@ phys_addr_t swiotlb_tbl_map_single(struc
- 	for (i = 0; i < nr_slots(alloc_size + offset); i++)
- 		mem->slots[index + i].orig_addr = slot_addr(orig_addr, i);
- 	tlb_addr = slot_addr(mem->start, index) + offset;
--	/*
--	 * When dir == DMA_FROM_DEVICE we could omit the copy from the orig
--	 * to the tlb buffer, if we knew for sure the device will
--	 * overwirte the entire current content. But we don't. Thus
--	 * unconditional bounce may prevent leaking swiotlb content (i.e.
--	 * kernel memory) to user-space.
--	 */
--	swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE);
-+	if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
-+	    (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE ||
-+	    dir == DMA_BIDIRECTIONAL))
-+		swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_TO_DEVICE);
- 	return tlb_addr;
- }
- 
-@@ -701,13 +697,10 @@ void swiotlb_tbl_unmap_single(struct dev
- void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
- 		size_t size, enum dma_data_direction dir)
- {
--	/*
--	 * Unconditional bounce is necessary to avoid corruption on
--	 * sync_*_for_cpu or dma_ummap_* when the device didn't overwrite
--	 * the whole lengt of the bounce buffer.
--	 */
--	swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
--	BUG_ON(!valid_dma_direction(dir));
-+	if (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)
-+		swiotlb_bounce(dev, tlb_addr, size, DMA_TO_DEVICE);
-+	else
-+		BUG_ON(dir != DMA_FROM_DEVICE);
- }
- 
- void swiotlb_sync_single_for_cpu(struct device *dev, phys_addr_t tlb_addr,