From: Jeremy Linton <jli@greshamstorage.com>
To: James Bottomley <James.Bottomley@SteelEye.com>,
Linux Scsi <linux-scsi@vger.kernel.org>,
Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers.
Date: Wed, 11 Jul 2007 19:38:56 -0500 [thread overview]
Message-ID: <46957820.9090008@greshamstorage.com> (raw)
Any function which use scsi_execute_async() and transfers "odd" sized
data that doesn't align correctly with the segment sizes may have its
transfer length padded out to the closest segment size.
For writes, this results in unnecessary data being transfered to the
SCSI target. For reads, it affects the residual data length being
returned to the application since the residual length will be based on
the padded transfer size rather than the actual request size.
The easiest way to see this is by trying to read using the SG_IO ioctl a
large (>32k) buffer size from a tape device that only has a few bytes of
data stored for the current block. The resulting resid will generally be
incorrect.
I've fixed this simply by changing scsi_req_map_sg() so that it places
the requested transfer length in rq->data_len rather than the sum of all
the sg segments.
This patch applies against scsi_lib.c in 2.6.22.
Signed-off-by: Jeremy Linton <jli@greshamstorage.com>
--- linux-2.6.22/drivers/scsi/scsi_lib.c.orig 2007-07-11
19:07:06.000000000 -0500
+++ linux-2.6.22/drivers/scsi/scsi_lib.c 2007-07-11
18:43:36.000000000 -0500
@@ -350,7 +350,7 @@ static int scsi_req_map_sg(struct reques
}
rq->buffer = rq->data = NULL;
- rq->data_len = data_len;
+ rq->data_len = bufflen;
return 0;
free_bios:
next reply other threads:[~2007-07-12 0:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-12 0:38 Jeremy Linton [this message]
2007-07-12 1:19 ` [PATCH][BUG] Incorrect SCSI transfer length computation from odd sized scsi_execute_async() transfers Mike Christie
2007-07-12 2:25 ` Jeremy Linton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46957820.9090008@greshamstorage.com \
--to=jli@greshamstorage.com \
--cc=James.Bottomley@SteelEye.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox