[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: [PATCH] scsi-generic scatter-gather residuals
From:       Gérard_Roudier <groudier () free ! fr>
Date:       2001-09-18 18:44:34
[Download RAW message or body]



On Mon, 17 Sep 2001, Douglas Gilbert wrote:

> Gérard Roudier wrote:
> >
> > On Mon, 17 Sep 2001, Tony Battersby wrote:
> >
> > > Hello,
> > >
> > > My name is Tony Battersby; I work for a company called Cybernetics that
> > > specializes in tape backup solutions.  I am currently developing the
> > > embedded firmware for a SCSI control unit for tape drives that runs Linux.
> > >
> > > My code uses the SCSI Generic driver to access tape drives connected to a
> > > LSI Logic 53c8XX controller board.  I am using the sym53c8xx.o driver for
> > > low-level SCSI access.  I am using kernel 2.4.9 (unmodified Linus tree),
> > > which comes with the 3.1.19 sg driver.
> > >
> > > My code relies on correct data transfer residuals (requested amount minus
> > > actual amount transferred) for operation, and there is no way around it.  I
> > > encountered a problem in the kernel where the residual was calculated
> > > incorrectly in some circumstances, causing my program to fail.
> > >
> > > After investigating the problem, I found that the sg driver was creating a
> > > scatter-gather list for the low-level driver whose length entries added up
> > > to more than the requested data transfer length.  It did this on purpose
> > > evidently for the convenience of allocating memory in blocks.  However, the
> > > sym53c8xx driver did not account for this overlength in its residual
> > > calculation, leading to an incorrect residual returned.
> > >
> > > The patch I have provided below (against kernel 2.4.9, or sg 3.1.19) fixes
> > > the problem by having the sg driver truncate the length of the last
> > > scatter-gather element so that the sum of all scatter-gather element lengths
> > > is equal to the requested transfer length.  An alternate solution would be
> > > to have the sym53c8xx driver check for the overage when processing the
> > > scatter-gather list.
> >
> > The alternate solution is obviously not acceptable.
> > Residual = requested transfer length - actual length transferred.
> > (as you pointed out)
> > What is allocated is up to the requester and low-level drivers haven't to
> > care about.
> > Thanks, anyway, for your fix done in the right place, in my opinion.
>
> I have been down this path and it oopses the aha1542
> driver which wants an even length on each scatter gather
> element.
>
> There seems to be some confusion that Eric may like
> to comment on. The sg driver puts the actual data
> transfer length (i.e. dxfer_len in CAM3) in the
> 4th argument of scsi_do_req(). This will end up
> in Scsi_Cmnd::bufflen. [N.B. If scatter gather is being
> used then the length of the scatter gather list is placed
> in sglist_len.]
>
> Now the sg driver sets up individual scatter gather element
> lengths to meet the worst case alignment requirement of any
> adapter. Therefore:
>   bufflen <= sum_of(scatter_gather_element_lengths)
> It is bufflen that should be used for resid calculations.
>
> The trouble is if I am correct then both the sym53c8xx
> and advansys drivers (and I only checked 2) are wrong
> since they deduce the transfer length under scatter gather
> by summing the lengths of each scatter gather element.

Nobody is wrong when there is no specification to refer to. :-)
Btw, at least, this 'bufflen' things is badly named.
Thanks anyway for the clarification.

Gérard.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]