> From: Sarah Sharp [mailto:[email protected]]
> On Wed, Nov 20, 2013 at 09:36:11AM -0000, David Laight wrote:
> > > From: Alan Stern [mailto:[email protected]]
> > > 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
