From: Greg Kroah-Hartman Date: Sun, 27 Mar 2022 09:32:31 +0000 (+0200) Subject: drop swiotlb patches from 5.10 and 5.4 X-Git-Tag: v4.9.309~9 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=50bed0d69bfcac7d96bc1b9e10df77e9200f3247;p=thirdparty%2Fkernel%2Fstable-queue.git drop swiotlb patches from 5.10 and 5.4 --- diff --git a/queue-5.10/series b/queue-5.10/series index 651d663c5bb..b1e4c571d36 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -7,8 +7,6 @@ cgroup-v1-correct-privileges-check-in-release_agent-writes.patch tpm-fix-error-handling-in-async-work.patch staging-fbtft-fb_st7789v-reset-display-before-initialization.patch llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch -swiotlb-fix-info-leak-with-dma_from_device.patch -swiotlb-rework-fix-info-leak-with-dma_from_device.patch asoc-sti-fix-deadlock-via-snd_pcm_stop_xrun-call.patch alsa-oss-fix-pcm-oss-buffer-allocation-overflow.patch alsa-usb-audio-add-mapping-for-new-corsair-virtuoso-se.patch diff --git a/queue-5.10/swiotlb-fix-info-leak-with-dma_from_device.patch b/queue-5.10/swiotlb-fix-info-leak-with-dma_from_device.patch deleted file mode 100644 index cbaf516be13..00000000000 --- a/queue-5.10/swiotlb-fix-info-leak-with-dma_from_device.patch +++ /dev/null @@ -1,103 +0,0 @@ -From ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e Mon Sep 17 00:00:00 2001 -From: Halil Pasic -Date: Fri, 11 Feb 2022 02:12:52 +0100 -Subject: swiotlb: fix info leak with DMA_FROM_DEVICE - -From: Halil Pasic - -commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream. - -The problem I'm addressing was discovered by the LTP test covering -cve-2018-1000204. - -A short description of what happens follows: -1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO - interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV - and a corresponding dxferp. The peculiar thing about this is that TUR - is not reading from the device. -2) In sg_start_req() the invocation of blk_rq_map_user() effectively - bounces the user-space buffer. As if the device was to transfer into - it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in - sg_build_indirect()") we make sure this first bounce buffer is - allocated with GFP_ZERO. -3) For the rest of the story we keep ignoring that we have a TUR, so the - device won't touch the buffer we prepare as if the we had a - DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device - and the buffer allocated by SG is mapped by the function - virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here - scatter-gather and not scsi generics). This mapping involves bouncing - via the swiotlb (we need swiotlb to do virtio in protected guest like - s390 Secure Execution, or AMD SEV). -4) When the SCSI TUR is done, we first copy back the content of the second - (that is swiotlb) bounce buffer (which most likely contains some - previous IO data), to the first bounce buffer, which contains all - zeros. Then we copy back the content of the first bounce buffer to - the user-space buffer. -5) The test case detects that the buffer, which it zero-initialized, - ain't all zeros and fails. - -One can argue that this is an swiotlb problem, because without swiotlb -we leak all zeros, and the swiotlb should be transparent in a sense that -it does not affect the outcome (if all other participants are well -behaved). - -Copying the content of the original buffer into the swiotlb buffer is -the only way I can think of to make swiotlb transparent in such -scenarios. So let's do just that if in doubt, but allow the driver -to tell us that the whole mapped buffer is going to be overwritten, -in which case we can preserve the old behavior and avoid the performance -impact of the extra bounce. - -Signed-off-by: Halil Pasic -Signed-off-by: Christoph Hellwig -Signed-off-by: Greg Kroah-Hartman - ---- - Documentation/core-api/dma-attributes.rst | 8 ++++++++ - include/linux/dma-mapping.h | 8 ++++++++ - kernel/dma/swiotlb.c | 3 ++- - 3 files changed, 18 insertions(+), 1 deletion(-) - ---- 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 -@@ -598,7 +598,8 @@ phys_addr_t swiotlb_tbl_map_single(struc - - tlb_addr = slot_addr(io_tlb_start, index) + offset; - if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && -- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) -+ (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || -+ dir == DMA_BIDIRECTIONAL)) - swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); - return tlb_addr; - } diff --git a/queue-5.10/swiotlb-rework-fix-info-leak-with-dma_from_device.patch b/queue-5.10/swiotlb-rework-fix-info-leak-with-dma_from_device.patch deleted file mode 100644 index 6416dbd60bd..00000000000 --- a/queue-5.10/swiotlb-rework-fix-info-leak-with-dma_from_device.patch +++ /dev/null @@ -1,121 +0,0 @@ -From aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 Mon Sep 17 00:00:00 2001 -From: Halil Pasic -Date: Sat, 5 Mar 2022 18:07:14 +0100 -Subject: swiotlb: rework "fix info leak with DMA_FROM_DEVICE" - -From: Halil Pasic - -commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream. - -Unfortunately, we ended up merging an old version of the patch "fix info -leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph -(the swiotlb maintainer), he asked me to create an incremental fix -(after I have pointed this out the mix up, and asked him for guidance). -So here we go. - -The main differences between what we got and what was agreed are: -* swiotlb_sync_single_for_device is also required to do an extra bounce -* We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters -* The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE - must take precedence over DMA_ATTR_SKIP_CPU_SYNC - -Thus this patch removes DMA_ATTR_OVERWRITE, and makes -swiotlb_sync_single_for_device() bounce unconditionally (that is, also -when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale -data from the swiotlb buffer. - -Let me note, that if the size used with dma_sync_* API is less than the -size used with dma_[un]map_*, under certain circumstances we may still -end up with swiotlb not being transparent. In that sense, this is no -perfect fix either. - -To get this bullet proof, we would have to bounce the entire -mapping/bounce buffer. For that we would have to figure out the starting -address, and the size of the mapping in -swiotlb_sync_single_for_device(). While this does seem possible, there -seems to be no firm consensus on how things are supposed to work. - -Signed-off-by: Halil Pasic -Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE") -Cc: stable@vger.kernel.org -Reviewed-by: Christoph Hellwig -Signed-off-by: Linus Torvalds -Signed-off-by: Greg Kroah-Hartman ---- - Documentation/core-api/dma-attributes.rst | 8 -------- - include/linux/dma-mapping.h | 8 -------- - kernel/dma/swiotlb.c | 25 ++++++++++++++++--------- - 3 files changed, 16 insertions(+), 25 deletions(-) - ---- a/Documentation/core-api/dma-attributes.rst -+++ b/Documentation/core-api/dma-attributes.rst -@@ -130,11 +130,3 @@ 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,14 +62,6 @@ - #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 -@@ -597,10 +597,14 @@ phys_addr_t swiotlb_tbl_map_single(struc - io_tlb_orig_addr[index + i] = slot_addr(orig_addr, i); - - tlb_addr = slot_addr(io_tlb_start, index) + offset; -- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && -- (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || -- dir == DMA_BIDIRECTIONAL)) -- swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); -+ /* -+ * 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(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); - return tlb_addr; - } - -@@ -680,11 +684,14 @@ void swiotlb_tbl_sync_single(struct devi - BUG_ON(dir != DMA_TO_DEVICE); - break; - case SYNC_FOR_DEVICE: -- if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) -- swiotlb_bounce(orig_addr, tlb_addr, -- size, DMA_TO_DEVICE); -- else -- BUG_ON(dir != DMA_FROM_DEVICE); -+ /* -+ * 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(orig_addr, tlb_addr, -+ size, DMA_TO_DEVICE); -+ BUG_ON(!valid_dma_direction(dir)); - break; - default: - BUG(); diff --git a/queue-5.4/series b/queue-5.4/series index 5dcf5aa266b..0b00bbebdb6 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -7,8 +7,6 @@ tpm-fix-error-handling-in-async-work.patch staging-fbtft-fb_st7789v-reset-display-before-initialization.patch thermal-int340x-fix-memory-leak-in-int3400_notify.patch llc-fix-netdevice-reference-leaks-in-llc_ui_bind.patch -swiotlb-fix-info-leak-with-dma_from_device.patch -swiotlb-rework-fix-info-leak-with-dma_from_device.patch alsa-pcm-add-stream-lock-during-pcm-reset-ioctl-operations.patch alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-rode-nt-usb.patch alsa-cmipci-restore-aux-vol-on-suspend-resume.patch diff --git a/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch b/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch deleted file mode 100644 index dd68c42c956..00000000000 --- a/queue-5.4/swiotlb-fix-info-leak-with-dma_from_device.patch +++ /dev/null @@ -1,104 +0,0 @@ -From ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e Mon Sep 17 00:00:00 2001 -From: Halil Pasic -Date: Fri, 11 Feb 2022 02:12:52 +0100 -Subject: swiotlb: fix info leak with DMA_FROM_DEVICE - -From: Halil Pasic - -commit ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e upstream. - -The problem I'm addressing was discovered by the LTP test covering -cve-2018-1000204. - -A short description of what happens follows: -1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO - interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV - and a corresponding dxferp. The peculiar thing about this is that TUR - is not reading from the device. -2) In sg_start_req() the invocation of blk_rq_map_user() effectively - bounces the user-space buffer. As if the device was to transfer into - it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in - sg_build_indirect()") we make sure this first bounce buffer is - allocated with GFP_ZERO. -3) For the rest of the story we keep ignoring that we have a TUR, so the - device won't touch the buffer we prepare as if the we had a - DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device - and the buffer allocated by SG is mapped by the function - virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here - scatter-gather and not scsi generics). This mapping involves bouncing - via the swiotlb (we need swiotlb to do virtio in protected guest like - s390 Secure Execution, or AMD SEV). -4) When the SCSI TUR is done, we first copy back the content of the second - (that is swiotlb) bounce buffer (which most likely contains some - previous IO data), to the first bounce buffer, which contains all - zeros. Then we copy back the content of the first bounce buffer to - the user-space buffer. -5) The test case detects that the buffer, which it zero-initialized, - ain't all zeros and fails. - -One can argue that this is an swiotlb problem, because without swiotlb -we leak all zeros, and the swiotlb should be transparent in a sense that -it does not affect the outcome (if all other participants are well -behaved). - -Copying the content of the original buffer into the swiotlb buffer is -the only way I can think of to make swiotlb transparent in such -scenarios. So let's do just that if in doubt, but allow the driver -to tell us that the whole mapped buffer is going to be overwritten, -in which case we can preserve the old behavior and avoid the performance -impact of the extra bounce. - -Signed-off-by: Halil Pasic -Signed-off-by: Christoph Hellwig -Signed-off-by: Greg Kroah-Hartman ---- - Documentation/DMA-attributes.txt | 10 ++++++++++ - include/linux/dma-mapping.h | 8 ++++++++ - kernel/dma/swiotlb.c | 3 ++- - 3 files changed, 20 insertions(+), 1 deletion(-) - ---- a/Documentation/DMA-attributes.txt -+++ b/Documentation/DMA-attributes.txt -@@ -156,3 +156,13 @@ 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_PRIVILEGED -+------------------- -+ -+Some advanced peripherals such as remote processors and GPUs perform -+accesses to DMA buffers in both privileged "supervisor" and unprivileged -+"user" modes. This attribute is used to indicate to the DMA-mapping -+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). ---- a/include/linux/dma-mapping.h -+++ b/include/linux/dma-mapping.h -@@ -71,6 +71,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. A CPU cannot - * reference a dma_addr_t directly because there may be translation between ---- a/kernel/dma/swiotlb.c -+++ b/kernel/dma/swiotlb.c -@@ -572,7 +572,8 @@ found: - for (i = 0; i < nslots; i++) - io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT); - if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && -- (dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) -+ (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || -+ dir == DMA_BIDIRECTIONAL)) - swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); - - return tlb_addr; diff --git a/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch b/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch deleted file mode 100644 index db413987bb6..00000000000 --- a/queue-5.4/swiotlb-rework-fix-info-leak-with-dma_from_device.patch +++ /dev/null @@ -1,123 +0,0 @@ -From aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 Mon Sep 17 00:00:00 2001 -From: Halil Pasic -Date: Sat, 5 Mar 2022 18:07:14 +0100 -Subject: swiotlb: rework "fix info leak with DMA_FROM_DEVICE" - -From: Halil Pasic - -commit aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13 upstream. - -Unfortunately, we ended up merging an old version of the patch "fix info -leak with DMA_FROM_DEVICE" instead of merging the latest one. Christoph -(the swiotlb maintainer), he asked me to create an incremental fix -(after I have pointed this out the mix up, and asked him for guidance). -So here we go. - -The main differences between what we got and what was agreed are: -* swiotlb_sync_single_for_device is also required to do an extra bounce -* We decided not to introduce DMA_ATTR_OVERWRITE until we have exploiters -* The implantation of DMA_ATTR_OVERWRITE is flawed: DMA_ATTR_OVERWRITE - must take precedence over DMA_ATTR_SKIP_CPU_SYNC - -Thus this patch removes DMA_ATTR_OVERWRITE, and makes -swiotlb_sync_single_for_device() bounce unconditionally (that is, also -when dir == DMA_TO_DEVICE) in order do avoid synchronising back stale -data from the swiotlb buffer. - -Let me note, that if the size used with dma_sync_* API is less than the -size used with dma_[un]map_*, under certain circumstances we may still -end up with swiotlb not being transparent. In that sense, this is no -perfect fix either. - -To get this bullet proof, we would have to bounce the entire -mapping/bounce buffer. For that we would have to figure out the starting -address, and the size of the mapping in -swiotlb_sync_single_for_device(). While this does seem possible, there -seems to be no firm consensus on how things are supposed to work. - -Signed-off-by: Halil Pasic -Fixes: ddbd89deb7d3 ("swiotlb: fix info leak with DMA_FROM_DEVICE") -Cc: stable@vger.kernel.org -Reviewed-by: Christoph Hellwig -Signed-off-by: Linus Torvalds -Signed-off-by: Greg Kroah-Hartman ---- - Documentation/DMA-attributes.txt | 10 ---------- - include/linux/dma-mapping.h | 8 -------- - kernel/dma/swiotlb.c | 25 ++++++++++++++++--------- - 3 files changed, 16 insertions(+), 27 deletions(-) - ---- a/Documentation/DMA-attributes.txt -+++ b/Documentation/DMA-attributes.txt -@@ -156,13 +156,3 @@ 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_PRIVILEGED --------------------- -- --Some advanced peripherals such as remote processors and GPUs perform --accesses to DMA buffers in both privileged "supervisor" and unprivileged --"user" modes. This attribute is used to indicate to the DMA-mapping --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). ---- a/include/linux/dma-mapping.h -+++ b/include/linux/dma-mapping.h -@@ -71,14 +71,6 @@ - #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. A CPU cannot - * reference a dma_addr_t directly because there may be translation between ---- a/kernel/dma/swiotlb.c -+++ b/kernel/dma/swiotlb.c -@@ -571,10 +571,14 @@ found: - */ - for (i = 0; i < nslots; i++) - io_tlb_orig_addr[index+i] = orig_addr + (i << IO_TLB_SHIFT); -- if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) && -- (!(attrs & DMA_ATTR_OVERWRITE) || dir == DMA_TO_DEVICE || -- dir == DMA_BIDIRECTIONAL)) -- swiotlb_bounce(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); -+ /* -+ * 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(orig_addr, tlb_addr, mapping_size, DMA_TO_DEVICE); - - return tlb_addr; - } -@@ -649,11 +653,14 @@ void swiotlb_tbl_sync_single(struct devi - BUG_ON(dir != DMA_TO_DEVICE); - break; - case SYNC_FOR_DEVICE: -- if (likely(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL)) -- swiotlb_bounce(orig_addr, tlb_addr, -- size, DMA_TO_DEVICE); -- else -- BUG_ON(dir != DMA_FROM_DEVICE); -+ /* -+ * 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(orig_addr, tlb_addr, -+ size, DMA_TO_DEVICE); -+ BUG_ON(!valid_dma_direction(dir)); - break; - default: - BUG();