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/[email protected]/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
