On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote: > > > On 6/18/2021 11:40 PM, Claire Chang wrote: > > 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 <tien...@chromium.org> > > Reviewed-by: Christoph Hellwig <h...@lst.de> > > Tested-by: Stefano Stabellini <sstabell...@kernel.org> > > Tested-by: Will Deacon <w...@kernel.org> > > Acked-by: Stefano Stabellini <sstabell...@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
