From: Jens Axboe <jens.axboe@oracle.com>
To: Boaz Harrosh <bharrosh@panasas.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
linux-scsi <linux-scsi@vger.kernel.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Mike Christie <michaelc@cs.wisc.edu>, Pete Wyckoff <pw@osc.edu>,
Benny Halevy <bhalevy@panasas.com>
Subject: Re: [PATCH 2/3] scsi_data_buffer
Date: Thu, 8 Nov 2007 14:54:37 +0100 [thread overview]
Message-ID: <20071108135437.GP5011@kernel.dk> (raw)
In-Reply-To: <473312AE.3000605@panasas.com>
On Thu, Nov 08 2007, Boaz Harrosh wrote:
> James, Jens please note the question below
> It is something that bothers me about sr.c
>
> On Tue, Nov 06 2007 at 20:19 +0200, Boaz Harrosh <bharrosh@panasas.com> wrote:
> > In preparation for bidi we abstract all IO members of scsi_cmnd,
> > that will need to duplicate, into a substructure.
> >
> <snip>
> >
> > - sd.c and sr.c
> > * sd and sr would adjust IO size to align on device's block
> > size so code needs to change once we move to scsi_data_buff
> > implementation.
> > * Convert code to use scsi_for_each_sg
> > * Use data accessors where appropriate.
> > * Remove dead code (req_data_dir() != READ && != WRITE)
> >
> <snip>
> > diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> > index 7702681..6d3bf41 100644
> > --- a/drivers/scsi/sr.c
> > +++ b/drivers/scsi/sr.c
> > @@ -226,7 +226,7 @@ out:
> > static int sr_done(struct scsi_cmnd *SCpnt)
> > {
> > int result = SCpnt->result;
> > - int this_count = SCpnt->request_bufflen;
> > + int this_count = scsi_bufflen(SCpnt);
> > int good_bytes = (result == 0 ? this_count : 0);
> > int block_sectors = 0;
> > long error_sector;
> > @@ -368,23 +368,21 @@ static int sr_prep_fn(struct request_queue *q, struct request *rq)
> > } else if (rq_data_dir(rq) == READ) {
> > SCpnt->cmnd[0] = READ_10;
> > SCpnt->sc_data_direction = DMA_FROM_DEVICE;
> > - } else {
> > - blk_dump_rq_flags(rq, "Unknown sr command");
> > - goto out;
> > }
> >
> > {
> > - struct scatterlist *sg = SCpnt->request_buffer;
> > - int i, size = 0;
> > - for (i = 0; i < SCpnt->use_sg; i++)
> > - size += sg[i].length;
> > + struct scatterlist *sg;
> > + int i, size = 0, sg_count = scsi_sg_count(SCpnt);
> > +
> > + scsi_for_each_sg (SCpnt, sg, sg_count, i)
> > + size += sg->length;
> >
> > - if (size != SCpnt->request_bufflen && SCpnt->use_sg) {
> > + if (size != scsi_bufflen(SCpnt)) {
> > scmd_printk(KERN_ERR, SCpnt,
> > "mismatch count %d, bytes %d\n",
> > - size, SCpnt->request_bufflen);
> > - if (SCpnt->request_bufflen > size)
> > - SCpnt->request_bufflen = size;
> > + size, scsi_bufflen(SCpnt));
> > + if (scsi_bufflen(SCpnt) > size)
> > + SCpnt->sdb.length = size;
> > }
> > }
> >
> > @@ -392,12 +390,12 @@ static int sr_prep_fn(struct request_queue *q, struct request *rq)
> > * request doesn't start on hw block boundary, add scatter pads
> > */
> > if (((unsigned int)rq->sector % (s_size >> 9)) ||
> > - (SCpnt->request_bufflen % s_size)) {
> > + (scsi_bufflen(SCpnt) % s_size)) {
> > scmd_printk(KERN_NOTICE, SCpnt, "unaligned transfer\n");
> > goto out;
> > }
> Here we check I/O is "large-block" aligned. Both start and size
>
> >
> > - this_count = (SCpnt->request_bufflen >> 9) / (s_size >> 9);
> > + this_count = (scsi_bufflen(SCpnt) >> 9) / (s_size >> 9);
> >
> Number of "large-blocks"
>
> >
> > SCSI_LOG_HLQUEUE(2, printk("%s : %s %d/%ld 512 byte blocks.\n",
> > @@ -411,7 +409,7 @@ static int sr_prep_fn(struct request_queue *q, struct request *rq)
> >
> > if (this_count > 0xffff) {
> > this_count = 0xffff;
> > - SCpnt->request_bufflen = this_count * s_size;
> > + SCpnt->sdb.length = this_count * s_size;
> > }
> >
> Here is my problem:
> In the case that the transfer is bigger than 0xffff * s_size
> (512/1024/2048) we modify ->request_bufflen. Now this has two bad
> effects, the way I understand it, please fix me in my
> misunderstanding.
>
> 1. Later in sr_done doing return good_bytes=cmd->request_bufflen will
> only complete the cut-out bytes. Meaning possible BIO leak, since the
> original request_bufflen was lost. (not all bytes are completed)
>
>
> 2. What mechanics will re-send, or even knows, that not the complete
> request was transfered? The way I understand it, a cmnd->resid must be
> set, in this case. Now the normal cmnd->resid is not enough because
> it will be written by drivers, sr needs to stash a resid somewhere and
> add it to cmnd->resid in sr_done(). But ...
>
It's not lost, the request will be requeued in scsi_end_request(). The
original state is in the request structure, and end_that_request_chunk()
will return not-done when you complete this first part.
--
Jens Axboe
next prev parent reply other threads:[~2007-11-08 13:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-06 18:04 [0/3] Last 3 patches for bidi support Boaz Harrosh
2007-11-06 18:16 ` [PATCH 1/3] scsi_tgt_lib: Use scsi_init_io instead of scsi_alloc_sgtable Boaz Harrosh
2007-11-08 3:13 ` FUJITA Tomonori
2007-11-08 8:32 ` Benny Halevy
2007-11-08 13:04 ` FUJITA Tomonori
2007-11-08 14:01 ` Boaz Harrosh
2007-11-08 14:20 ` FUJITA Tomonori
2007-11-06 18:19 ` [PATCH 2/3] scsi_data_buffer Boaz Harrosh
2007-11-08 3:14 ` FUJITA Tomonori
2007-11-08 9:24 ` Boaz Harrosh
2007-11-08 13:03 ` FUJITA Tomonori
2007-11-08 13:53 ` Boaz Harrosh
2007-11-08 13:44 ` Boaz Harrosh
2007-11-08 13:54 ` Jens Axboe [this message]
2007-11-08 14:17 ` Boaz Harrosh
2007-11-06 18:23 ` [PATCH 3/3] SCSI: bidi support Boaz Harrosh
2007-11-06 18:25 ` [0/3] Last 3 patches for " Mike Christie
2007-11-06 18:38 ` Boaz Harrosh
2007-11-08 3:13 ` FUJITA Tomonori
2007-11-08 16:49 ` [0/4 ver2] " Boaz Harrosh
2007-11-08 16:56 ` [PATCH 1/4] sr/sd: Remove dead code Boaz Harrosh
2007-11-08 16:57 ` [PATCH 2/4] tgt: Use scsi_init_io instead of scsi_alloc_sgtable Boaz Harrosh
2007-11-08 16:59 ` [PATCH 3/4] scsi_data_buffer Boaz Harrosh
2007-11-13 6:06 ` Andrew Morton
2007-11-13 6:40 ` FUJITA Tomonori
2007-11-13 7:07 ` Andrew Morton
2007-11-13 7:26 ` FUJITA Tomonori
2007-11-13 9:17 ` Boaz Harrosh
2007-11-08 17:03 ` [PATCH 4/4] SCSI: bidi support Boaz Harrosh
2007-11-09 21:15 ` Kiyoshi Ueda
[not found] ` <47383020.8010108@panasas.com>
2007-11-12 19:52 ` Kiyoshi Ueda
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=20071108135437.GP5011@kernel.dk \
--to=jens.axboe@oracle.com \
--cc=James.Bottomley@SteelEye.com \
--cc=bhalevy@panasas.com \
--cc=bharrosh@panasas.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=pw@osc.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.