The patch below does not apply to the 5.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 5f89468e2f060031cd89fd4287298e0eaf246bf6 Mon Sep 17 00:00:00 2001
From: Bumyong Lee bumyong.lee@samsung.com Date: Mon, 10 May 2021 18:10:04 +0900 Subject: [PATCH] swiotlb: manipulate orig_addr when tlb_addr has offset MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit
in case of driver wants to sync part of ranges with offset, swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with offset and ends up with data mismatch.
It was removed from "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single", but said logic has to be added back in.
From Linus's email:
"That commit which the removed the offset calculation entirely, because the old
(unsigned long)tlb_addr & (IO_TLB_SIZE - 1)
was wrong, but instead of removing it, I think it should have just fixed it to be
(tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
instead. That way the slot offset always matches the slot index calculation."
(Unfortunatly that broke NVMe).
The use-case that drivers are hitting is as follow:
1. Get dma_addr_t from dma_map_single()
dma_addr_t tlb_addr = dma_map_single(dev, vaddr, vsize, DMA_TO_DEVICE);
|<---------------vsize------------->| +-----------------------------------+ | | original buffer +-----------------------------------+ vaddr
swiotlb_align_offset |<----->|<---------------vsize------------->| +-------+-----------------------------------+ | | | swiotlb buffer +-------+-----------------------------------+ tlb_addr
2. Do something 3. Sync dma_addr_t through dma_sync_single_for_device(..)
dma_sync_single_for_device(dev, tlb_addr + offset, size, DMA_TO_DEVICE);
Error case. Copy data to original buffer but it is from base addr (instead of base addr + offset) in original buffer:
swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr
|<- size ->| +-----------------------------------+ |##########| | original buffer +-----------------------------------+ vaddr
The fix is to copy the data to the original buffer and take into account the offset, like so:
swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr
|<- offset ->|<- size ->| +-----------------------------------+ | |##########| | original buffer +-----------------------------------+ vaddr
[One fix which was Linus's that made more sense to as it created a symmetry would break NVMe. The reason for that is the: unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
would come up with the proper offset, but it would lose the alignment (which this patch contains).]
Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") Signed-off-by: Bumyong Lee bumyong.lee@samsung.com Signed-off-by: Chanho Park chanho61.park@samsung.com Reviewed-by: Christoph Hellwig hch@lst.de Reported-by: Dominique MARTINET dominique.martinet@atmark-techno.com Reported-by: Horia Geantă horia.geanta@nxp.com Tested-by: Horia Geantă horia.geanta@nxp.com CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk konrad.wilk@oracle.com
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 8ca7d505d61c..e50df8d8f87e 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -334,6 +334,14 @@ void __init swiotlb_exit(void) io_tlb_default_mem = NULL; }
+/* + * Return the offset into a iotlb slot required to keep the device happy. + */ +static unsigned int swiotlb_align_offset(struct device *dev, u64 addr) +{ + return addr & dma_get_min_align_mask(dev) & (IO_TLB_SIZE - 1); +} + /* * Bounce: copy the swiotlb buffer from or back to the original dma location */ @@ -346,10 +354,17 @@ static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t size size_t alloc_size = mem->slots[index].alloc_size; unsigned long pfn = PFN_DOWN(orig_addr); unsigned char *vaddr = phys_to_virt(tlb_addr); + unsigned int tlb_offset;
if (orig_addr == INVALID_PHYS_ADDR) return;
+ tlb_offset = (tlb_addr & (IO_TLB_SIZE - 1)) - + swiotlb_align_offset(dev, orig_addr); + + orig_addr += tlb_offset; + alloc_size -= tlb_offset; + if (size > alloc_size) { dev_WARN_ONCE(dev, 1, "Buffer overflow detected. Allocation size: %zu. Mapping size: %zu.\n", @@ -390,14 +405,6 @@ static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t size
#define slot_addr(start, idx) ((start) + ((idx) << IO_TLB_SHIFT))
-/* - * Return the offset into a iotlb slot required to keep the device happy. - */ -static unsigned int swiotlb_align_offset(struct device *dev, u64 addr) -{ - return addr & dma_get_min_align_mask(dev) & (IO_TLB_SIZE - 1); -} - /* * Carefully handle integer overflow which can occur when boundary_mask == ~0UL. */
From: Bumyong Lee bumyong.lee@samsung.com
commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. (Backported as different form due to absence of below patch series https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)
in case of driver wants to sync part of ranges with offset, swiotlb_tbl_sync_single() copies from orig_addr base to tlb_addr with offset and ends up with data mismatch.
It was removed from "swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single", but said logic has to be added back in.
From Linus's email:
"That commit which the removed the offset calculation entirely, because the old
(unsigned long)tlb_addr & (IO_TLB_SIZE - 1)
was wrong, but instead of removing it, I think it should have just fixed it to be
(tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
instead. That way the slot offset always matches the slot index calculation."
(Unfortunatly that broke NVMe).
The use-case that drivers are hitting is as follow:
1. Get dma_addr_t from dma_map_single()
dma_addr_t tlb_addr = dma_map_single(dev, vaddr, vsize, DMA_TO_DEVICE);
|<---------------vsize------------->| +-----------------------------------+ | | original buffer +-----------------------------------+ vaddr
swiotlb_align_offset |<----->|<---------------vsize------------->| +-------+-----------------------------------+ | | | swiotlb buffer +-------+-----------------------------------+ tlb_addr
2. Do something 3. Sync dma_addr_t through dma_sync_single_for_device(..)
dma_sync_single_for_device(dev, tlb_addr + offset, size, DMA_TO_DEVICE);
Error case. Copy data to original buffer but it is from base addr (instead of base addr + offset) in original buffer:
swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr
|<- size ->| +-----------------------------------+ |##########| | original buffer +-----------------------------------+ vaddr
The fix is to copy the data to the original buffer and take into account the offset, like so:
swiotlb_align_offset |<----->|<- offset ->|<- size ->| +-------+-----------------------------------+ | | |##########| | swiotlb buffer +-------+-----------------------------------+ tlb_addr
|<- offset ->|<- size ->| +-----------------------------------+ | |##########| | original buffer +-----------------------------------+ vaddr
[One fix which was Linus's that made more sense to as it created a symmetry would break NVMe. The reason for that is the: unsigned int offset = (tlb_addr - mem->start) & (IO_TLB_SIZE - 1);
would come up with the proper offset, but it would lose the alignment (which this patch contains).]
Fixes: 16fc3cef33a0 ("swiotlb: don't modify orig_addr in swiotlb_tbl_sync_single") Signed-off-by: Bumyong Lee bumyong.lee@samsung.com Signed-off-by: Chanho Park chanho61.park@samsung.com Reviewed-by: Christoph Hellwig hch@lst.de Reported-by: Dominique MARTINET dominique.martinet@atmark-techno.com Reported-by: Horia Geantă horia.geanta@nxp.com Tested-by: Horia Geantă horia.geanta@nxp.com CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk konrad.wilk@oracle.com --- kernel/dma/swiotlb.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index fe4c01c14ab2..e96f3808e431 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -724,11 +724,17 @@ void swiotlb_tbl_sync_single(struct device *hwdev, phys_addr_t tlb_addr, int index = (tlb_addr - io_tlb_start) >> IO_TLB_SHIFT; size_t orig_size = io_tlb_orig_size[index]; phys_addr_t orig_addr = io_tlb_orig_addr[index]; + unsigned int tlb_offset;
if (orig_addr == INVALID_PHYS_ADDR) return;
- validate_sync_size_and_truncate(hwdev, orig_size, &size); + tlb_offset = (tlb_addr & (IO_TLB_SIZE - 1)) - + swiotlb_align_offset(hwdev, orig_addr); + + orig_addr += tlb_offset; + + validate_sync_size_and_truncate(hwdev, orig_size - tlb_offset, &size);
switch (target) { case SYNC_FOR_CPU:
On Mon, Jun 28, 2021 at 03:59:16PM +0900, Chanho Park wrote:
From: Bumyong Lee bumyong.lee@samsung.com
commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. (Backported as different form due to absence of below patch series https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)
What stable kernel(s) is this for?
And did you send the same patch twice?
thanks,
greg k-h
commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. (Backported as different form due to absence of below patch series https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)
What stable kernel(s) is this for?
Hmm. I sent this with "--in-reply-to" option of git send-email with your e-mail's message-id but it didn't work well. This is for linux-5.12.y tree.
And did you send the same patch twice?
No. Unfortunately, they're different due to swiotlb patches. I backported the patch to each kernel versions respectively.
Best Regards, Chanho Park
On Mon, Jun 28, 2021 at 06:25:28PM +0900, Chanho Park wrote:
commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. (Backported as different form due to absence of below patch series https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)
What stable kernel(s) is this for?
Hmm. I sent this with "--in-reply-to" option of git send-email with your e-mail's message-id but it didn't work well.
That does not work when the message you are sending in-reply-to is no longer in the recipient's message box :)
This is for linux-5.12.y tree.
Great, thanks.
And did you send the same patch twice?
No. Unfortunately, they're different due to swiotlb patches. I backported the patch to each kernel versions respectively.
What is the "other" patch for?
greg k-h
That does not work when the message you are sending in-reply-to is no longer in the recipient's message box :)
Ah. Got it.
This is for linux-5.12.y tree.
Great, thanks.
And did you send the same patch twice?
No. Unfortunately, they're different due to swiotlb patches. I backported the patch to each kernel versions respectively.
What is the "other" patch for?
Another patch what I sent is for linux-5.10.y tree. Regarding linux-5.10.y's patch and linux-5.12.y's patch, below patch was applied only for linux-5.12.y tree and it made differences.
daf9514fd5eb swiotlb: Validate bounce size in the sync/unmap path
Best Regards, Chanho Park
On Mon, Jun 28, 2021 at 11:36:19AM +0200, 'Greg KH' wrote:
On Mon, Jun 28, 2021 at 06:25:28PM +0900, Chanho Park wrote:
commit 5f89468e2f060031cd89fd4287298e0eaf246bf6 upstream. (Backported as different form due to absence of below patch series https://lore.kernel.org/linux-iommu/20210301074436.919889-1-hch@lst.de/)
What stable kernel(s) is this for?
Hmm. I sent this with "--in-reply-to" option of git send-email with your e-mail's message-id but it didn't work well.
That does not work when the message you are sending in-reply-to is no longer in the recipient's message box :)
This is for linux-5.12.y tree.
Great, thanks.
And did you send the same patch twice?
No. Unfortunately, they're different due to swiotlb patches. I backported the patch to each kernel versions respectively.
What is the "other" patch for?
Looks like 5.10.y. Both now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org