On Fri, 3 Nov 2023, Keith Busch wrote: > On Fri, Nov 03, 2023 at 09:30:07PM +0100, Marek Marczykowski-G'orecki wrote: > > On Fri, Nov 03, 2023 at 10:54:00AM -0600, Keith Busch wrote: > > > On Fri, Nov 03, 2023 at 05:15:49PM +0100, Marek Marczykowski-G'orecki wrote: > > > > On Thu, Nov 02, 2023 at 06:06:33PM +0100, Mikulas Patocka wrote: > > > > > Then, try this patch (without "iommu=panic"), reproduce the deadlock and > > > > > tell us which one of the "printk" statements is triggered during the > > > > > deadlock. > > > > > > > > The "821" one - see below. > > > > > > Thanks for confirming! > > > > > > Could you try this patch? > > > > Besides min3() being unhappy about types, it works. > > Oops, should have changed the constant to "ul" instead of just "u". > > Anyway, the overall idea makes sense to me, but I don't know the swiotlb > stuff well. > > Christoph, does that patch make sense? For reference: > > https://lore.kernel.org/linux-mm/ZUOr-vp0yRkLyvyi@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/T/#m8d34245e0eef43f8e9fe6cba6038d77ed2a93ad6 dma_opt_mapping_size returns "min(dma_max_mapping_size(dev), size)". So you don't have to call dma_max_mapping_size explicitly, you can leave the file drivers/nvme/host/pci.c as it is. What about the other block device drivers (AHCI, SCSI...)? Should there be some generic framework that restricts max_hw_sectors according to dma_opt_mapping_size? Mikulas
