Re: [PATCH] block: fix residual byte count handling

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <htejun@...>
Cc: <tomof@...>, <jens.axboe@...>, <James.Bottomley@...>, <efault@...>, <akpm@...>, <linux-kernel@...>, <linux-ide@...>, <linux-scsi@...>, <jgarzik@...>, <fujita.tomonori@...>
Date: Sunday, March 2, 2008 - 11:59 pm

On Mon, 03 Mar 2008 11:40:08 +0900
Tejun Heo <htejun@gmail.com> wrote:


Yeah. It meant the requested transfer length from userland in the past
and I think that chaning to the length of mapped sg list doesn't make
anything simpler.



The drivers care about the actual data buffer size.

The dumb controllers drivers can get what they want to use
rq->extra_len or walk through the sg list.



If we add extra_len, we can get what raw_data_len and data_len
provide.


I can't see what changing the meaning of rq->data_len (and
investigating all the block drivers) gives us.



No problem. It would be much better to add blk_rq_total_data_len
rather than chainging the meaning of rq->data_len and all the block
drivers.

Here's an updated patch (I forgot to remove the bi_size adjustment in
blk_rq_map_user in the previous patch). Can we agree on it if we add
blk_rq_total_data_len()?


diff --git a/block/blk-core.c b/block/blk-core.c
index 775c851..bfec406 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -127,7 +127,6 @@ void rq_init(struct request_queue *q, struct request *rq)
 	rq->nr_hw_segments = 0;
 	rq->ioprio = 0;
 	rq->special = NULL;
-	rq->raw_data_len = 0;
 	rq->buffer = NULL;
 	rq->tag = -1;
 	rq->errors = 0;
@@ -135,6 +134,7 @@ void rq_init(struct request_queue *q, struct request *rq)
 	rq->cmd_len = 0;
 	memset(rq->cmd, 0, sizeof(rq->cmd));
 	rq->data_len = 0;
+	rq->extra_len = 0;
 	rq->sense_len = 0;
 	rq->data = NULL;
 	rq->sense = NULL;
@@ -2016,7 +2016,6 @@ void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
 	rq->hard_cur_sectors = rq->current_nr_sectors;
 	rq->hard_nr_sectors = rq->nr_sectors = bio_sectors(bio);
 	rq->buffer = bio_data(bio);
-	rq->raw_data_len = bio->bi_size;
 	rq->data_len = bio->bi_size;
 
 	rq->bio = rq->biotail = bio;
diff --git a/block/blk-map.c b/block/blk-map.c
index 09f7fd0..f559832 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -19,7 +19,6 @@ int blk_rq_append_bio(struct request_queue *q, struct request *rq,
 		rq->biotail->bi_next = bio;
 		rq->biotail = bio;
 
-		rq->raw_data_len += bio->bi_size;
 		rq->data_len += bio->bi_size;
 	}
 	return 0;
@@ -151,11 +150,8 @@ int blk_rq_map_user(struct request_queue *q, struct request *rq,
 	 */
 	if (len & queue_dma_alignment(q)) {
 		unsigned int pad_len = (queue_dma_alignment(q) & ~len) + 1;
-		struct bio *bio = rq->biotail;
 
-		bio->bi_io_vec[bio->bi_vcnt - 1].bv_len += pad_len;
-		bio->bi_size += pad_len;
-		rq->data_len += pad_len;
+		rq->extra_len += pad_len;
 	}
 
 	rq->buffer = rq->data = NULL;
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 7506c4f..0f58616 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -231,7 +231,7 @@ new_segment:
 			    ((unsigned long)q->dma_drain_buffer) &
 			    (PAGE_SIZE - 1));
 		nsegs++;
-		rq->data_len += q->dma_drain_size;
+		rq->extra_len += q->dma_drain_size;
 	}
 
 	if (sg)
diff --git a/block/bsg.c b/block/bsg.c
index 7f3c095..8917c51 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -437,14 +437,14 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, struct sg_io_v4 *hdr,
 	}
 
 	if (rq->next_rq) {
-		hdr->dout_resid = rq->raw_data_len;
-		hdr->din_resid = rq->next_rq->raw_data_len;
+		hdr->dout_resid = rq->data_len;
+		hdr->din_resid = rq->next_rq->data_len;
 		blk_rq_unmap_user(bidi_bio);
 		blk_put_request(rq->next_rq);
 	} else if (rq_data_dir(rq) == READ)
-		hdr->din_resid = rq->raw_data_len;
+		hdr->din_resid = rq->data_len;
 	else
-		hdr->dout_resid = rq->raw_data_len;
+		hdr->dout_resid = rq->data_len;
 
 	/*
 	 * If the request generated a negative error number, return it
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index e993cac..a2c3a93 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -266,7 +266,7 @@ static int blk_complete_sghdr_rq(struct request *rq, struct sg_io_hdr *hdr,
 	hdr->info = 0;
 	if (hdr->masked_status || hdr->host_status || hdr->driver_status)
 		hdr->info |= SG_INFO_CHECK;
-	hdr->resid = rq->raw_data_len;
+	hdr->resid = rq->data_len;
 	hdr->sb_len_wr = 0;
 
 	if (rq->sense_len && hdr->sbp) {
@@ -528,8 +528,8 @@ static int __blk_send_generic(struct request_queue *q, struct gendisk *bd_disk,
 	rq = blk_get_request(q, WRITE, __GFP_WAIT);
 	rq->cmd_type = REQ_TYPE_BLOCK_PC;
 	rq->data = NULL;
-	rq->raw_data_len = 0;
 	rq->data_len = 0;
+	rq->extra_len = 0;
 	rq->timeout = BLK_DEFAULT_SG_TIMEOUT;
 	memset(rq->cmd, 0, sizeof(rq->cmd));
 	rq->cmd[0] = cmd;
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 7b1f1ee..fe47922 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -2538,7 +2538,7 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
 	}
 
 	qc->tf.command = ATA_CMD_PACKET;
-	qc->nbytes = scsi_bufflen(scmd);
+	qc->nbytes = scsi_bufflen(scmd) + scmd->request->extra_len;
 
 	/* check whether ATAPI DMA is safe */
 	if (!using_pio && ata_check_atapi_dma(qc))
@@ -2549,7 +2549,7 @@ static unsigned int atapi_xlat(struct ata_queued_cmd *qc)
 	 * want to set it properly, and for DMA where it is
 	 * effectively meaningless.
 	 */
-	nbytes = min(scmd->request->raw_data_len, (unsigned int)63 * 1024);
+	nbytes = min(scmd->request->data_len, (unsigned int)63 * 1024);
 
 	/* Most ATAPI devices which honor transfer chunk size don't
 	 * behave according to the spec when odd chunk size which
@@ -2875,7 +2875,7 @@ static unsigned int ata_scsi_pass_thru(struct ata_queued_cmd *qc)
 	 * TODO: find out if we need to do more here to
 	 *       cover scatter/gather case.
 	 */
-	qc->nbytes = scsi_bufflen(scmd);
+	qc->nbytes = scsi_bufflen(scmd) + scmd->request->extra_len;
 
 	/* request result TF and be quiet about device error */
 	qc->flags |= ATA_QCFLAG_RESULT_TF | ATA_QCFLAG_QUIET;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 6fe67d1..b72526c 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -216,8 +216,8 @@ struct request {
 	unsigned int cmd_len;
 	unsigned char cmd[BLK_MAX_CDB];
 
-	unsigned int raw_data_len;
 	unsigned int data_len;
+	unsigned int extra_len;	/* length of alignment and padding */
 	unsigned int sense_len;
 	void *data;
 	void *sense;
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
regression: CD burning (k3b) went broke, Mike Galbraith, (Thu Feb 21, 4:42 am)
Re: regression: CD burning (k3b) went broke, Jens Axboe, (Fri Feb 22, 3:32 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Sat Feb 23, 3:42 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Sun Feb 24, 3:54 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Tue Feb 26, 5:48 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Tue Feb 26, 9:36 am)
Re: regression: CD burning (k3b) went broke, Andrew Morton, (Tue Feb 26, 7:08 pm)
Re: regression: CD burning (k3b) went broke, Jeff Garzik, (Tue Feb 26, 8:46 pm)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Tue Feb 26, 10:58 pm)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Tue Feb 26, 10:24 pm)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Wed Feb 27, 2:00 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Wed Feb 27, 3:07 am)
Re: regression: CD burning (k3b) went broke, Tejun Heo, (Thu Feb 28, 3:43 am)
Re: regression: CD burning (k3b) went broke, Mike Galbraith, (Thu Feb 28, 4:20 am)
[PATCH] block: fix residual byte count handling, Tejun Heo, (Thu Feb 28, 4:50 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Thu Feb 28, 11:35 am)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Thu Feb 28, 11:46 am)
Re: [PATCH] block: fix residual byte count handling, James Bottomley, (Fri Feb 29, 12:47 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Fri Feb 29, 4:11 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Sun Mar 2, 10:52 am)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Sun Mar 2, 10:40 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Sun Mar 2, 11:59 pm)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Mon Mar 3, 12:09 am)
Re: [PATCH] block: separate out padding from alignment, James Bottomley, (Mon Mar 3, 2:27 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 4:26 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 8:17 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 9:50 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 10:01 am)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Mon Mar 3, 10:22 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 10:52 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Mon Mar 3, 10:11 pm)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Mon Mar 3, 10:32 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 4:53 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 4:59 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 5:06 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 5:22 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 5:35 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 5:46 am)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 8:37 am)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 9:30 am)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Tue Mar 4, 12:17 pm)
Re: [PATCH] block: fix residual byte count handling, Tejun Heo, (Tue Mar 4, 12:42 pm)
Re: [PATCH] block: fix residual byte count handling, Boaz Harrosh, (Tue Mar 4, 2:26 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 3:19 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Tue Mar 4, 8:26 pm)
Re: [PATCH] block: fix residual byte count handling, FUJITA Tomonori, (Thu Mar 6, 12:56 am)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 2:45 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 3:25 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 3:33 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 3:34 pm)
Re: [PATCH] block: fix residual byte count handling, James Bottomley, (Tue Mar 4, 2:27 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 8:45 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 8:39 am)
Re: [PATCH] block: fix residual byte count handling, Kiyoshi Ueda, (Tue Mar 4, 3:42 pm)
Re: [PATCH] block: fix residual byte count handling, James Bottomley, (Tue Mar 4, 12:04 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 2:46 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 8:43 am)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 8:58 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 9:03 am)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 10:25 am)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 2:17 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 2:29 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 2:35 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 2:45 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 2:49 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 2:54 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Tue Mar 4, 3:26 pm)
Re: [PATCH] block: fix residual byte count handling, Jens Axboe, (Tue Mar 4, 3:28 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Christie, (Sun Mar 2, 2:46 pm)
Re: [PATCH] block: fix residual byte count handling, Mike Galbraith, (Sun Mar 2, 11:27 pm)
Re: [PATCH] block: fix residual byte count handling, James Bottomley, (Sat Mar 1, 11:19 am)