linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
@ 2008-01-26  0:57 FUJITA Tomonori
  2008-01-26  2:05 ` James Bottomley
  0 siblings, 1 reply; 5+ messages in thread
From: FUJITA Tomonori @ 2008-01-26  0:57 UTC (permalink / raw)
  To: James.Bottomley; +Cc: linux-scsi, bharrosh, pw, fujita.tomonori

This is against the scsi-bidi tree.

We need to use the cmd_type of a leading request for scsi_init_sgtable
to set up scsi_data_buffer:length of a bidi request properly.

An alternative approach is setting the cmd_type of a leading request
and its bidi request (*1). But the block layer and scsi-ml don't
expect that the leading request and its sub-requests have the
different command types.

Note that scsi_debug's XDWRITEREAD_10 support is fine without this
patch since req->nr_sectors works for it but req->nr_sectors doesn't
work for everyone.

(*1)

http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html

=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable

We need to use the cmd_type of a leading request for scsi_init_sgtable
to set up scsi_data_buffer:length of its bidi request properly.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 drivers/scsi/scsi_lib.c |   23 ++++++++++++++---------
 1 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index e1c7eeb..61093ea 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1001,8 +1001,9 @@ void scsi_io_completion(struct scsi_cmnd *cmd, unsigned int good_bytes)
 	scsi_end_request(cmd, -EIO, this_count, !result);
 }
 
-static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb,
-			     gfp_t gfp_mask)
+static int scsi_init_sgtable(struct request *req,
+			     enum rq_cmd_type_bits cmd_type,
+			     struct scsi_data_buffer *sdb, gfp_t gfp_mask)
 {
 	int count;
 
@@ -1015,12 +1016,12 @@ static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb,
 	}
 
 	req->buffer = NULL;
-	if (blk_pc_request(req))
+	if (cmd_type == REQ_TYPE_BLOCK_PC)
 		sdb->length = req->data_len;
 	else
 		sdb->length = req->nr_sectors << 9;
 
-	/* 
+	/*
 	 * Next, walk the list, and fill in the addresses and sizes of
 	 * each segment.
 	 */
@@ -1043,21 +1044,25 @@ static int scsi_init_sgtable(struct request *req, struct scsi_data_buffer *sdb,
  */
 int scsi_init_io(struct scsi_cmnd *cmd, gfp_t gfp_mask)
 {
-	int error = scsi_init_sgtable(cmd->request, &cmd->sdb, gfp_mask);
+	int error;
+	enum rq_cmd_type_bits cmd_type = cmd->request->cmd_type;
+
+	error = scsi_init_sgtable(cmd->request, cmd_type, &cmd->sdb, gfp_mask);
 	if (error)
 		goto err_exit;
 
 	if (blk_bidi_rq(cmd->request)) {
-		struct scsi_data_buffer *bidi_sdb = kmem_cache_zalloc(
-			scsi_bidi_sdb_cache, GFP_ATOMIC);
+		struct scsi_data_buffer *bidi_sdb;
+
+		bidi_sdb = kmem_cache_zalloc(scsi_bidi_sdb_cache, GFP_ATOMIC);
 		if (!bidi_sdb) {
 			error = BLKPREP_DEFER;
 			goto err_exit;
 		}
 
 		cmd->request->next_rq->special = bidi_sdb;
-		error = scsi_init_sgtable(cmd->request->next_rq, bidi_sdb,
-								    GFP_ATOMIC);
+		error = scsi_init_sgtable(cmd->request->next_rq, cmd_type,
+					  bidi_sdb, GFP_ATOMIC);
 		if (error)
 			goto err_exit;
 	}
-- 
1.5.3.4


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
  2008-01-26  0:57 [PATCH] use the cmd_type of a leading request for scsi_init_sgtable FUJITA Tomonori
@ 2008-01-26  2:05 ` James Bottomley
  2008-01-26  2:22   ` FUJITA Tomonori
  2008-01-26  2:34   ` Pete Wyckoff
  0 siblings, 2 replies; 5+ messages in thread
From: James Bottomley @ 2008-01-26  2:05 UTC (permalink / raw)
  To: FUJITA Tomonori; +Cc: linux-scsi, bharrosh, pw, fujita.tomonori

On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote:
> This is against the scsi-bidi tree.
> 
> We need to use the cmd_type of a leading request for scsi_init_sgtable
> to set up scsi_data_buffer:length of a bidi request properly.
> 
> An alternative approach is setting the cmd_type of a leading request
> and its bidi request (*1). But the block layer and scsi-ml don't
> expect that the leading request and its sub-requests have the
> different command types.
> 
> Note that scsi_debug's XDWRITEREAD_10 support is fine without this
> patch since req->nr_sectors works for it but req->nr_sectors doesn't
> work for everyone.
> 
> (*1)
> 
> http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html
> 
> =
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
> 
> We need to use the cmd_type of a leading request for scsi_init_sgtable
> to set up scsi_data_buffer:length of its bidi request properly.

This seems to be a very convoluted work around for the fact that we
forgot to set the cmd_type on the subordinate request.

Wouldn't this be a better fix?

James

---

diff --git a/block/bsg.c b/block/bsg.c
index 69b0a9d..8917c51 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
 			goto out;
 		}
 		rq->next_rq = next_rq;
+		next_rq->cmd_type = rq->cmd_type;
 
 		dxferp = (void*)(unsigned long)hdr->din_xferp;
 		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
  2008-01-26  2:05 ` James Bottomley
@ 2008-01-26  2:22   ` FUJITA Tomonori
  2008-01-26  2:28     ` FUJITA Tomonori
  2008-01-26  2:34   ` Pete Wyckoff
  1 sibling, 1 reply; 5+ messages in thread
From: FUJITA Tomonori @ 2008-01-26  2:22 UTC (permalink / raw)
  To: James.Bottomley; +Cc: tomof, linux-scsi, bharrosh, pw, fujita.tomonori

On Fri, 25 Jan 2008 20:05:55 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote:
> > This is against the scsi-bidi tree.
> > 
> > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > to set up scsi_data_buffer:length of a bidi request properly.
> > 
> > An alternative approach is setting the cmd_type of a leading request
> > and its bidi request (*1). But the block layer and scsi-ml don't
> > expect that the leading request and its sub-requests have the
> > different command types.
> > 
> > Note that scsi_debug's XDWRITEREAD_10 support is fine without this
> > patch since req->nr_sectors works for it but req->nr_sectors doesn't
> > work for everyone.
> > 
> > (*1)
> > 
> > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html
> > 
> > =
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
> > 
> > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > to set up scsi_data_buffer:length of its bidi request properly.
> 
> This seems to be a very convoluted work around for the fact that we
> forgot to set the cmd_type on the subordinate request.
> 
> Wouldn't this be a better fix?

I'm fine with this. I have no big preference in this issue.

Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>


I just thought that the approach (the block layer and scsi-ml look at
only the type of a leading request) show better how the block layer
and scsi-ml see a leading request and its subordinate requests (all
the requests need to have the same command type).


> James
> 
> ---
> 
> diff --git a/block/bsg.c b/block/bsg.c
> index 69b0a9d..8917c51 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
>  			goto out;
>  		}
>  		rq->next_rq = next_rq;
> +		next_rq->cmd_type = rq->cmd_type;
>  
>  		dxferp = (void*)(unsigned long)hdr->din_xferp;
>  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> 
> 
> -
> 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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
  2008-01-26  2:22   ` FUJITA Tomonori
@ 2008-01-26  2:28     ` FUJITA Tomonori
  0 siblings, 0 replies; 5+ messages in thread
From: FUJITA Tomonori @ 2008-01-26  2:28 UTC (permalink / raw)
  To: James.Bottomley; +Cc: linux-scsi, bharrosh, pw, fujita.tomonori

On Sat, 26 Jan 2008 11:22:47 +0900
FUJITA Tomonori <tomof@acm.org> wrote:

> On Fri, 25 Jan 2008 20:05:55 -0600
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote:
> > > This is against the scsi-bidi tree.
> > > 
> > > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > > to set up scsi_data_buffer:length of a bidi request properly.
> > > 
> > > An alternative approach is setting the cmd_type of a leading request
> > > and its bidi request (*1). But the block layer and scsi-ml don't
> > > expect that the leading request and its sub-requests have the
> > > different command types.
> > > 
> > > Note that scsi_debug's XDWRITEREAD_10 support is fine without this
> > > patch since req->nr_sectors works for it but req->nr_sectors doesn't
> > > work for everyone.
> > > 
> > > (*1)
> > > 
> > > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html
> > > 
> > > =
> > > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
> > > 
> > > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > > to set up scsi_data_buffer:length of its bidi request properly.
> > 
> > This seems to be a very convoluted work around for the fact that we
> > forgot to set the cmd_type on the subordinate request.
> > 
> > Wouldn't this be a better fix?
> 
> I'm fine with this. I have no big preference in this issue.
> 
> Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> 
> 
> I just thought that the approach (the block layer and scsi-ml look at
> only the type of a leading request) show better how the block layer
> and scsi-ml see a leading request and its subordinate requests (all
> the requests need to have the same command type).

I meant that the block layer and scsi-ml use its subordinate requests
just to hook data buffer.


Anyway, I'm fine with your patch.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
  2008-01-26  2:05 ` James Bottomley
  2008-01-26  2:22   ` FUJITA Tomonori
@ 2008-01-26  2:34   ` Pete Wyckoff
  1 sibling, 0 replies; 5+ messages in thread
From: Pete Wyckoff @ 2008-01-26  2:34 UTC (permalink / raw)
  To: James Bottomley; +Cc: FUJITA Tomonori, linux-scsi, bharrosh, fujita.tomonori

James.Bottomley@HansenPartnership.com wrote on Fri, 25 Jan 2008 20:05 -0600:
> On Sat, 2008-01-26 at 09:57 +0900, FUJITA Tomonori wrote:
> > This is against the scsi-bidi tree.
> > 
> > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > to set up scsi_data_buffer:length of a bidi request properly.
> > 
> > An alternative approach is setting the cmd_type of a leading request
> > and its bidi request (*1). But the block layer and scsi-ml don't
> > expect that the leading request and its sub-requests have the
> > different command types.
> > 
> > Note that scsi_debug's XDWRITEREAD_10 support is fine without this
> > patch since req->nr_sectors works for it but req->nr_sectors doesn't
> > work for everyone.
> > 
> > (*1)
> > 
> > http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg12669.html
> > 
> > =
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Subject: [PATCH] use the cmd_type of a leading request for scsi_init_sgtable
> > 
> > We need to use the cmd_type of a leading request for scsi_init_sgtable
> > to set up scsi_data_buffer:length of its bidi request properly.
> 
> This seems to be a very convoluted work around for the fact that we
> forgot to set the cmd_type on the subordinate request.
> 
> Wouldn't this be a better fix?
> 
> James
> 
> ---
> 
> diff --git a/block/bsg.c b/block/bsg.c
> index 69b0a9d..8917c51 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -279,6 +279,7 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
>  			goto out;
>  		}
>  		rq->next_rq = next_rq;
> +		next_rq->cmd_type = rq->cmd_type;
>  
>  		dxferp = (void*)(unsigned long)hdr->din_xferp;
>  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> 
> 

Agree.  I did essentially the same thing in:

http://marc.info/?l=linux-scsi&m=119835555623270

Tomo, you may want to have a look at all the bsg patches I sent back
in Dec 2007.  Boaz has the minimum required for bidi in his tree.
There are a few more here too, if you want to see what we need for OSD:

http://git.osc.edu/?p=linux.git;a=summary

		-- Pete

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-01-26  2:34 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-26  0:57 [PATCH] use the cmd_type of a leading request for scsi_init_sgtable FUJITA Tomonori
2008-01-26  2:05 ` James Bottomley
2008-01-26  2:22   ` FUJITA Tomonori
2008-01-26  2:28     ` FUJITA Tomonori
2008-01-26  2:34   ` Pete Wyckoff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).