> From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx] > On Wed, Nov 20, 2013 at 09:36:11AM -0000, David Laight wrote: > > > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > > > On Tue, 19 Nov 2013, Sarah Sharp wrote: > > > > > > > The xHCI driver can limit the number of sg-list entries through > > > > hcd->self.sg_tablesize. It's currently set to ~0, which is "however > > > > many entries you want. You could set that to the number of TRBs in a > > > > segment (minus one for the link TRB). > > > > ... > > Ok, so the networking layer should be fine. However, with the current > patch, if the mass storage driver sends down a scatter-gather list > that's bigger than a ring segment, or needs to be split up so it doesn't > cross 64K boundaries, then the URB submission will fail. We don't want > that to happen. > > At the very least, we should limit hcd->self.sg_tablesize in > drivers/usb/host/xhci.c to 63 (TRBS_PER_SEGMENT - 1). But we could > still potentially run into the 64K boundary issue in one or maybe all of > those entries. Would it be crazy to limit the number of entries to half > that (31)? It may impact performance, but it ensures that SCSI reads > and writes don't randomly fail. We can always increase the ring segment > size in a later patch. Unless there is a limit on the overall length of the transfer you'll always lose. An aligned 4MB transfer in a contiguous memory buffer requires 64 TRBs. So won't fit in a ring segment. Although I'd guess that such transfers are unusual. If you bet that crossing a 64k boundaries is unusual then 32 is probably a sane limit. Fragments over 16k can easily be split between ring segments - so a more complex check could allow for that - but it won't be quick to write. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
