Re: [usb-storage] Re: 2 PATCHES: fix request_tranferlength

[Douglas Gilbert <dougg@torque.net>]

Matthew Dharm wrote:
> 
> On Tue, Jul 30, 2002 at 09:40:12AM -0400, Douglas Gilbert wrote:
> > Matthew Dharm wrote:
> > >
> > > Out of curiosity... which value does the sg interface pass through?  It
> > > collects both the buffer length and the requested transfer length, if my
> > > memory serves...
> >
> > Matt,
> > The sg driver does not attempt to decode SCSI commands (and,
> > for example, calculate allocation lengths) but simply passes
> > them through. In the sg_io_hdr interface what the user gives
> > as dxfer_len becomes the 4th argument to scsi_do_req() and
> > hence becomes Scsi_Request::sr_bufflen in the mid and lower
> > levels. The cumulative length of the elements in scatter gather
> > list built by sg (or the single buffer) is greater than or
> > equal to dxfer_len.
> 
> Hrm....
> 
> Are you saying then that the sum of the sg segments can be greater than the
> requested length?

Yes.
For indirect IO this shouldn't be a problem as dxfer_len
is used for the copy_to_user(). For direct IO, overrunning
the dxfer_len is a little more suspect.
 
> After some discussions with Linus and others, I was under the impression
> that this was a no-no...

The venerable aha1542 used to panic if it every received
an odd scatter gather element size. Also most modern
PCI SCSI controllers are DMAing from a 16 bit SPI bus and
an odd count seems to cause some of them mild indigestion.


Doug Ledford <dledford@redhat.com> wrote:
> But, in practice, I think the real answer is that the length 
> of all the elements in the sg list == dxfer_len in all cases.

In sd and sr probably. In sg consider this code comment:
/* round request up to next highest SG_SECTOR_SZ byte boundary */

That code was there from the original sg driver (lk 2.0 and
before). I took it out, got burnt, then put it back in.

 
Doug Gilbert