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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alan,

> From: Alan Stern, Sent: Tuesday, July 2, 2019 11:28 PM
> 
> 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.

I'm sorry, but I cannot understand what are important DMA fields.
IIUC, usb-storage driver should take care of calling blk_queue_ APIs anyway because:

 - As Christoph mentioned before on the email [1], usb-storage has a special
   max_sectors quirk for tape and SuperSpeed devices.
 - Since blk_queue_* APIs don't take device structure pointer, the block layer
   cannot call any DMA mapping APIs. So, even if any other DMA fields are copied,
   the behavior is not changed.

[1]
https://www.spinics.net/lists/linux-usb/msg181527.html

What do you think?

Best regards,
Yoshihiro Shimoda

> 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





[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux