RE: [PATCH v2] usb-storage: Add a limitation for blk_queue_max_hw_sectors()

[Alan Stern <stern@rowland.harvard.edu>]

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