Thread (29 messages) 29 messages, 7 authors, 2021-06-24

Re: [PATCH v14 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

From: Will Deacon <will@kernel.org>
Date: 2021-06-23 18:37:51
Also in: dri-devel, intel-gfx, linux-devicetree, linux-iommu, linux-pci, linuxppc-dev, xen-devel

On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:

On 6/18/2021 11:40 PM, Claire Chang wrote:
quoted
Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
use it to determine whether to bounce the data or not. This will be
useful later to allow for different pools.

Signed-off-by: Claire Chang <redacted>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Stefano Stabellini <sstabellini@kernel.org>
Tested-by: Will Deacon <will@kernel.org>
Acked-by: Stefano Stabellini <sstabellini@kernel.org>
Reverting the rest of the series up to this patch fixed a boot crash with NVMe on today's linux-next.
Hmm, so that makes patch 7 the suspicious one, right?

Looking at that one more closely, it looks like swiotlb_find_slots() takes
'alloc_size + offset' as its 'alloc_size' parameter from
swiotlb_tbl_map_single() and initialises 'mem->slots[i].alloc_size' based
on 'alloc_size + offset', which looks like a change in behaviour from the
old code, which didn't include the offset there.

swiotlb_release_slots() then adds the offset back on afaict, so we end up
accounting for it twice and possibly unmap more than we're supposed to?

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help