On Tue, 2 Jul 2019, Yoshihiro Shimoda wrote: > Hi Alan, shuah, Suwan, > > > From: Christoph Hellwig, Sent: Monday, June 17, 2019 3:22 PM > > > > On Mon, Jun 17, 2019 at 04:17:43AM +0000, Yoshihiro Shimoda wrote: > > > Thank you for the comments. So, should I wait for getting rid of the > > > virt_boundary_mask stuff? If I revise the commit log of this patch, > > > is it acceptable for v5.2-stable as a workaround? In other words, > > > I worry about this issue exists on v5.2-stable. > > > > It does exist on 5.2-stable and we should fix it. I'll plan to resend > > my series to fix the virt_boundary issues for the other SCSI driver > > soon, but we'll still need to sort out usb-storage. > > I guess that getting rid of the virt_boundary_mask stuff [1] needs more time. > So, for v5.2-stable, would you accept my patch as a workaround? > JFYI, v5.2-rc7 still has this "swiotlb buffer is full" issue. > > [1] > https://marc.info/?l=linux-kernel&m=156114524808042&w=2 I would really prefer to see a different solution. The actual problem is that the usb_device and usb_interface structures are supposed to inherit all of their DMA properties from the bus's host controller. But the existing code copies only the dma_mask and dma_pfn_offset fields in the embedded device structures. If we copied all of the important DMA fields then this patch wouldn't be needed; the max_sectors value for the request queue would be set up correctly to begin with. So what I would like to see is a new subroutine -- perhaps in the driver core -- that copies the DMA fields from one struct device to another. Then we could call this subroutine in usb_alloc_dev() and usb_set_configuration() instead of copying the information manually. Greg and Christoph, does that make sense? Yoshihiro, would you like to write a patch that does this? Alan Stern
