Skip to contentSkip to conversation

bidi support: block layer bidirectional io.

PATCH In review Boaz Harrosh 8 participants 25 messages Apr 15, 2007 – May 4, 2007

Subsystems (16)
lore
Share & tools
lore
#0 lore raw

cover bidi support: block layer bidirectional io.

Following are 4 (large) patches for support of bidirectional block I/O in kernel. (not including SCSI-ml or iSCSI)

The submitted work is against linux-2.6-block tree as of 2007/04/15, and will only cleanly apply in succession.

The patches are based on the RFC I sent 3 months ago. They only cover the block layer at this point. I suggest they get included in Morton's tree until they reach the kernel so they can get compiled on all architectures/platforms. There is still a chance that architectures I did not compile were not fully converted. (FWIW, my search for use of struct request members failed to find them). If you find such a case, please send me the file name and I will fix it ASAP.

Patches summary:
1. [PATCH 1/4] bidi support: request dma_data_direction
- Convert REQ_RW bit flag to a dma_data_direction member like in SCSI-ml use.
- removed rq_data_dir() and added other APIs for querying request's direction.
- fix usage of rq_data_dir() and peeking at req->cmd_flags & REQ_RW to using new api.
- clean-up bad usage of DMA_BIDIRECTIONAL and bzero of none-queue requests, to use the new blk_rq_init_unqueued_req()

2. [PATCH 2/4] bidi support: fix req->cmd == INT cases
- Digging into all these old drivers, I have found traces of past life where request->cmd was the command type. This patch fixes some of these places. All drivers touched by this patch are clear indication of drivers that were not used for a while. Should we removed them from Kernel? These Are:
drivers/acorn/block/fd1772.c, drivers/acorn/block/mfmhd.c, drivers/block/nbd.c, drivers/cdrom/aztcd.c, drivers/cdrom/cm206.c drivers/cdrom/gscd.c, drivers/cdrom/mcdx.c, drivers/cdrom/optcd.c drivers/cdrom/sjcd.c, drivers/ide/legacy/hd.c, drivers/block/amiflop.c

2. [PATCH 3/4] bidi support: request_io_part
- extract io related fields in struct request into struct request_io_part in preparation to full bidi support.
- new rq_uni() API to access the sub-structure. (Please read below comment on why an API and not open code the access)
- Convert All users to new API.

3. [PATCH 4/4] bidi support: bidirectional block layer
- add one more request_io_part member for bidi support in struct request.
- add block layer API functions for mapping and accessing bidi data buffers and for ending a block request as a whole (end_that_request_block())

--------------------------------------------------------------------------------------------
Developer comments:

patch 1/4: Borrow from struct scsi_cmnd use of enum dma_data_direction. Further work (in progress) is the removal of the corresponding member from struct scsi_cmnd and converting all users to directly access rq_dma_dir(sc->req).

patch 3/4: The reasons for introducing the rq_uni(req) API rather than directly accessing req->uni are:

* WARN(!bidi_dir(req)) is life saving when developing bidi enabled paths. Once we, bidi users, start to push bidi requests down the kernel paths, we immediately get warned of paths we did not anticipate. Otherwise, they will be very hard to find, and will hurt kernel stability.

* A cleaner and saner future implementation could be in/out members rather than uni/bidi_read. This way the dma_direction member can deprecated and the uni sub- structure can be maintained using a pointer in struct req.
With this API we are free to change the implementation in the future without touching any users of the API. We can also experiment with what's best. Also, with the API it is much easier to convert uni-directional drivers for bidi (look in ll_rw_block.c in patch 4/4).

* Note, that internal uses inside the block layer access req->uni directly, as they will need to be changed if the implementation of req->{uni, bidi_read} changes.

#1 lore raw

PATCH 1/4 bidi support: request dma_data_direction

- Introduce a new enum dma_data_direction data_dir member in struct request. and remove the RW bit from request->cmd_flag
- Add new API to query request direction.
- Adjust existing API and implementation.
- Cleanup wrong use of DMA_BIDIRECTIONAL
- Introduce new blk_rq_init_unqueued_req() and use it in places ad-hoc requests were used and bzero'ed.

---
 arch/um/drivers/ubd_kern.c      |    4 +-
 block/as-iosched.c              |    2 +-
 block/cfq-iosched.c             |   10 ++--
 block/deadline-iosched.c        |    8 ++--
 block/elevator.c                |   11 ++--
 block/ll_rw_blk.c               |  113 ++++++++++++++++++++++++---------------
 block/scsi_ioctl.c              |   10 ++--
 drivers/block/DAC960.c          |    2 +-
 drivers/block/amiflop.c         |    4 +-
 drivers/block/ataflop.c         |    2 +-
 drivers/block/cciss.c           |    6 +-
 drivers/block/cpqarray.c        |    6 +-
 drivers/block/floppy.c          |    9 +--
 drivers/block/nbd.c             |    3 +-
 drivers/block/paride/pcd.c      |    2 +-
 drivers/block/paride/pd.c       |   29 +++++------
 drivers/block/paride/pf.c       |    9 +---
 drivers/block/pktcdvd.c         |    2 +-
 drivers/block/ps2esdi.c         |    9 ++--
 drivers/block/swim3.c           |   26 +++++-----
 drivers/block/sx8.c             |    6 +-
 drivers/block/ub.c              |    8 +--
 drivers/block/viodasd.c         |    2 +-
 drivers/block/xd.c              |    4 +-
 drivers/block/z2ram.c           |    2 +-
 drivers/cdrom/cdrom.c           |    2 +-
 drivers/cdrom/cdu31a.c          |    2 +-
 drivers/cdrom/gscd.c            |    2 +-
 drivers/cdrom/sbpcd.c           |    2 +-
 drivers/cdrom/sonycd535.c       |    2 +-
 drivers/cdrom/viocd.c           |    2 +-
 drivers/ide/arm/icside.c        |    7 +--
 drivers/ide/cris/ide-cris.c     |    4 +-
 drivers/ide/ide-cd.c            |   13 +++--
 drivers/ide/ide-disk.c          |   10 ++--
 drivers/ide/ide-dma.c           |    4 +-
 drivers/ide/ide-floppy.c        |    4 +-
 drivers/ide/ide-io.c            |    5 +-
 drivers/ide/ide-tape.c          |    2 +-
 drivers/ide/ide-taskfile.c      |    6 +-
 drivers/ide/ide.c               |    4 +-
 drivers/ide/legacy/hd.c         |    6 +-
 drivers/ide/mips/au1xxx-ide.c   |    7 +--
 drivers/ide/pci/alim15x3.c      |    2 +-
 drivers/ide/pci/hpt366.c        |    2 +-
 drivers/ide/pci/pdc202xx_old.c  |    2 +-
 drivers/ide/pci/scc_pata.c      |    2 +-
 drivers/ide/pci/sgiioc4.c       |    4 +-
 drivers/ide/pci/trm290.c        |    2 +-
 drivers/ide/ppc/pmac.c          |    5 +-
 drivers/md/dm-emc.c             |    2 +-
 drivers/message/i2o/i2o_block.c |    8 ++--
 drivers/mmc/mmc_block.c         |   13 +++--
 drivers/mtd/mtd_blkdevs.c       |    8 ++--
 drivers/s390/block/dasd.c       |    2 +-
 drivers/s390/block/dasd_diag.c  |    4 +-
 drivers/s390/block/dasd_eckd.c  |   10 ++--
 drivers/s390/block/dasd_fba.c   |   14 +++---
 drivers/s390/char/tape_block.c  |    2 +-
 drivers/sbus/char/jsflash.c     |    2 +-
 drivers/scsi/aic7xxx_old.c      |    4 +-
 drivers/scsi/scsi_error.c       |    3 +-
 drivers/scsi/scsi_lib.c         |   21 +++----
 drivers/scsi/scsi_tgt_lib.c     |   29 ++++-------
 drivers/scsi/sd.c               |   20 ++++---
 drivers/scsi/sg.c               |    2 -
 drivers/scsi/sr.c               |   15 +++---
 drivers/scsi/sun3_NCR5380.c     |    6 +-
 include/linux/blkdev.h          |   53 ++++++++++++++++---
 include/linux/blktrace_api.h    |    8 +++-
 include/linux/dma-mapping.h     |   22 ++++++++
 include/linux/elevator.h        |    4 +-
 72 files changed, 359 insertions(+), 285 deletions(-)
arch/um/drivers/ubd_kern.c +2 -2
index 8bd9204..222ad17 100644
@@ -1030,7 +1030,7 @@ static int prepare_request(struct request *req, struct io_thread_req *io_req)
     int len;
 
     /* This should be impossible now */
-    if((rq_data_dir(req) == WRITE) && !ubd_dev->openflags.w){
+    if((rq_rw_dir(req) == WRITE) && !ubd_dev->openflags.w){
         printk("Write attempted on readonly ubd device %s\n",
                disk->disk_name);
         end_request(req, 0);
@@ -1049,7 +1049,7 @@ static int prepare_request(struct request *req, struct io_thread_req *io_req)
     io_req->error = 0;
     io_req->sector_mask = 0;
 
-    io_req->op = (rq_data_dir(req) == READ) ? UBD_READ : UBD_WRITE;
+    io_req->op = (rq_uni_rw_dir(req) == READ) ? UBD_READ : UBD_WRITE;
     io_req->offsets[0] = 0;
     io_req->offsets[1] = ubd_dev->cow.data_offset;
     io_req->buffer = req->buffer;
block/as-iosched.c +1 -1
index ef12627..824d93e 100644
@@ -1285,7 +1285,7 @@ static void as_work_handler(struct work_struct *work)
     spin_unlock_irqrestore(q->queue_lock, flags);
 }
 
-static int as_may_queue(request_queue_t *q, int rw)
+static int as_may_queue(request_queue_t *q, int rw, int is_sync)
 {
     int ret = ELV_MQUEUE_MAY;
     struct as_data *ad = q->elevator->elevator_data;
block/cfq-iosched.c +5 -5
index b6491c0..882a15a 100644
@@ -226,7 +226,7 @@ static inline pid_t cfq_queue_pid(struct task_struct *task, int rw, int is_sync)
     /*
      * Use the per-process queue, for read requests and syncronous writes
      */
-    if (!(rw & REQ_RW) || is_sync)
+    if (!(rw == WRITE) || is_sync)
         return task->pid;
 
     return CFQ_KEY_ASYNC;
@@ -1787,14 +1787,14 @@ static inline int __cfq_may_queue(struct cfq_queue *cfqq)
     return ELV_MQUEUE_MAY;
 }
 
-static int cfq_may_queue(request_queue_t *q, int rw)
+static int cfq_may_queue(request_queue_t *q, int rw, int is_sync)
 {
     struct cfq_data *cfqd = q->elevator->elevator_data;
     struct task_struct *tsk = current;
     struct cfq_queue *cfqq;
     unsigned int key;
 
-    key = cfq_queue_pid(tsk, rw, rw & REQ_RW_SYNC);
+    key = cfq_queue_pid(tsk, rw, is_sync);
 
     /*
      * don't force setup of a queue from here, as a call to may_queue
@@ -1821,7 +1821,7 @@ static void cfq_put_request(struct request *rq)
     struct cfq_queue *cfqq = RQ_CFQQ(rq);
 
     if (cfqq) {
-        const int rw = rq_data_dir(rq);
+        const int rw = rq_rw_dir(rq);
 
         BUG_ON(!cfqq->allocated[rw]);
         cfqq->allocated[rw]--;
@@ -1844,7 +1844,7 @@ cfq_set_request(request_queue_t *q, struct request *rq, gfp_t gfp_mask)
     struct cfq_data *cfqd = q->elevator->elevator_data;
     struct task_struct *tsk = current;
     struct cfq_io_context *cic;
-    const int rw = rq_data_dir(rq);
+    const int rw = rq_rw_dir(rq);
     const int is_sync = rq_is_sync(rq);
     pid_t key = cfq_queue_pid(tsk, rw, is_sync);
     struct cfq_queue *cfqq;
block/deadline-iosched.c +4 -4
index 6d673e9..e605c09 100644
@@ -53,7 +53,7 @@ struct deadline_data {
 
 static void deadline_move_request(struct deadline_data *, struct request *);
 
-#define RQ_RB_ROOT(dd, rq)    (&(dd)->sort_list[rq_data_dir((rq))])
+#define RQ_RB_ROOT(dd, rq)    (&(dd)->sort_list[rq_rw_dir((rq))])
 
 static void
 deadline_add_rq_rb(struct deadline_data *dd, struct request *rq)
@@ -72,7 +72,7 @@ retry:
 static inline void
 deadline_del_rq_rb(struct deadline_data *dd, struct request *rq)
 {
-    const int data_dir = rq_data_dir(rq);
+    const int data_dir = rq_rw_dir(rq);
 
     if (dd->next_rq[data_dir] == rq) {
         struct rb_node *rbnext = rb_next(&rq->rb_node);
@@ -92,7 +92,7 @@ static void
 deadline_add_request(struct request_queue *q, struct request *rq)
 {
     struct deadline_data *dd = q->elevator->elevator_data;
-    const int data_dir = rq_data_dir(rq);
+    const int data_dir = rq_rw_dir(rq);
 
     deadline_add_rq_rb(dd, rq);
 
@@ -197,7 +197,7 @@ deadline_move_to_dispatch(struct deadline_data *dd, struct request *rq)
 static void
 deadline_move_request(struct deadline_data *dd, struct request *rq)
 {
-    const int data_dir = rq_data_dir(rq);
+    const int data_dir = rq_rw_dir(rq);
     struct rb_node *rbnext = rb_next(&rq->rb_node);
 
     dd->next_rq[READ] = NULL;
block/elevator.c +6 -5
index 96a00c8..b73feec 100644
@@ -76,7 +76,7 @@ inline int elv_rq_merge_ok(struct request *rq, struct bio *bio)
     /*
      * different data direction or already started, don't merge
      */
-    if (bio_data_dir(bio) != rq_data_dir(rq))
+    if (bio_data_dir(bio) != rq_rw_dir(rq))
         return 0;
 
     /*
@@ -413,7 +413,7 @@ void elv_dispatch_sort(request_queue_t *q, struct request *rq)
     list_for_each_prev(entry, &q->queue_head) {
         struct request *pos = list_entry_rq(entry);
 
-        if (rq_data_dir(rq) != rq_data_dir(pos))
+        if (rq_uni_rw_dir(rq) != rq_uni_rw_dir(pos))
             break;
         if (pos->cmd_flags & (REQ_SOFTBARRIER|REQ_HARDBARRIER|REQ_STARTED))
             break;
@@ -733,7 +733,8 @@ struct request *elv_next_request(request_queue_t *q)
             blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
         }
 
-        if (!q->boundary_rq || q->boundary_rq == rq) {
+        if ((!q->boundary_rq || q->boundary_rq == rq) &&
+            !rq_bidi_dir(rq)) {
             q->end_sector = rq_end_sector(rq);
             q->boundary_rq = NULL;
         }
@@ -845,12 +846,12 @@ void elv_put_request(request_queue_t *q, struct request *rq)
         e->ops->elevator_put_req_fn(rq);
 }
 
-int elv_may_queue(request_queue_t *q, int rw)
+int elv_may_queue(request_queue_t *q, int rw, int is_sync)
 {
     elevator_t *e = q->elevator;
 
     if (e->ops->elevator_may_queue_fn)
-        return e->ops->elevator_may_queue_fn(q, rw);
+        return e->ops->elevator_may_queue_fn(q, rw, is_sync);
 
     return ELV_MQUEUE_MAY;
 }
block/ll_rw_blk.c +70 -43

259 lines not on this page · raw message

block/scsi_ioctl.c +5 -5
index 65c6a3c..8fc6b65 100644
@@ -254,7 +254,8 @@ static int sg_io(struct file *file, request_queue_t *q,
             break;
         }
 
-    rq = blk_get_request(q, writing ? WRITE : READ, GFP_KERNEL);
+    rq = blk_get_request(q,
+        writing ? DMA_TO_DEVICE : DMA_FROM_DEVICE, GFP_KERNEL);
     if (!rq)
         return -ENOMEM;
 
@@ -410,7 +411,8 @@ int sg_scsi_ioctl(struct file *file, struct request_queue *q,
         memset(buffer, 0, bytes);
     }
 
-    rq = blk_get_request(q, in_len ? WRITE : READ, __GFP_WAIT);
+    rq = blk_get_request(q,
+        in_len ? DMA_TO_DEVICE : DMA_FROM_DEVICE, __GFP_WAIT);
 
     cmdlen = COMMAND_SIZE(opcode);
 
@@ -495,10 +497,8 @@ static int __blk_send_generic(request_queue_t *q, struct gendisk *bd_disk, int c
     struct request *rq;
     int err;
 
-    rq = blk_get_request(q, WRITE, __GFP_WAIT);
+    rq = blk_get_request(q, DMA_NONE, __GFP_WAIT);
     rq->cmd_type = REQ_TYPE_BLOCK_PC;
-    rq->data = NULL;
-    rq->data_len = 0;
     rq->timeout = BLK_DEFAULT_TIMEOUT;
     memset(rq->cmd, 0, sizeof(rq->cmd));
     rq->cmd[0] = cmd;
drivers/block/DAC960.c +1 -1
index 92bf868..8ba5142 100644
@@ -3322,7 +3322,7 @@ static int DAC960_process_queue(DAC960_Controller_T *Controller, struct request_
     if (Command == NULL)
         return 0;
 
-    if (rq_data_dir(Request) == READ) {
+    if (rq_uni_rw_dir(Request) == READ) {
         Command->DmaDirection = PCI_DMA_FROMDEVICE;
         Command->CommandType = DAC960_ReadCommand;
     } else {
drivers/block/amiflop.c +2 -2
index 5d65621..54f2fb3 100644
@@ -1379,7 +1379,7 @@ static void redo_fd_request(void)
                "0x%08lx\n", track, sector, data);
 #endif
 
-        if ((rq_data_dir(CURRENT) != READ) && (rq_data_dir(CURRENT) != WRITE)) {
+        if (!dma_uni_dir(CURRENT->data_dir)) {
             printk(KERN_WARNING "do_fd_request: unknown command\n");
             end_request(CURRENT, 0);
             goto repeat;
@@ -1389,7 +1389,7 @@ static void redo_fd_request(void)
             goto repeat;
         }
 
-        switch (rq_data_dir(CURRENT)) {
+        switch (rq_rw_dir(CURRENT)) {
         case READ:
             memcpy(data, floppy->trackbuf + sector * 512, 512);
             break;
drivers/block/ataflop.c +1 -1
index 14d6b94..b940802 100644
@@ -1453,7 +1453,7 @@ repeat:
     del_timer( &motor_off_timer );
 
     ReqCnt = 0;
-    ReqCmd = rq_data_dir(CURRENT);
+    ReqCmd = rq_uni_rw_dir(CURRENT);
     ReqBlock = CURRENT->sector;
     ReqBuffer = CURRENT->buffer;
     setup_req_params( drive );
drivers/block/cciss.c +3 -3
index 072e18e..d87eecc 100644
@@ -1237,7 +1237,7 @@ static void cciss_softirq_done(struct request *rq)
     complete_buffers(rq->bio, rq->errors);
 
     if (blk_fs_request(rq)) {
-        const int rw = rq_data_dir(rq);
+        const int rw = rq_rw_dir(rq);
 
         disk_stat_add(rq->rq_disk, sectors[rw], rq->nr_sectors);
     }
@@ -2501,10 +2501,10 @@ static void do_cciss_request(request_queue_t *q)
     c->Request.Type.Type = TYPE_CMD;    // It is a command.
     c->Request.Type.Attribute = ATTR_SIMPLE;
     c->Request.Type.Direction =
-        (rq_data_dir(creq) == READ) ? XFER_READ : XFER_WRITE;
+        (rq_uni_rw_dir(creq) == READ) ? XFER_READ : XFER_WRITE;
     c->Request.Timeout = 0;    // Don't time out
     c->Request.CDB[0] =
-        (rq_data_dir(creq) == READ) ? h->cciss_read : h->cciss_write;
+        (rq_uni_rw_dir(creq) == READ) ? h->cciss_read : h->cciss_write;
     start_blk = creq->sector;
 #ifdef CCISS_DEBUG
     printk(KERN_DEBUG "ciss: sector =%d nr_sectors=%d\n", (int)creq->sector,
drivers/block/cpqarray.c +3 -3
index b94cd1c..59b62cf 100644
@@ -922,7 +922,7 @@ DBGPX(
     seg = blk_rq_map_sg(q, creq, tmp_sg);
 
     /* Now do all the DMA Mappings */
-    if (rq_data_dir(creq) == READ)
+    if (rq_uni_rw_dir(creq) == READ)
         dir = PCI_DMA_FROMDEVICE;
     else
         dir = PCI_DMA_TODEVICE;
@@ -937,7 +937,7 @@ DBGPX(
 DBGPX(    printk("Submitting %d sectors in %d segments\n", creq->nr_sectors, seg); );
     c->req.hdr.sg_cnt = seg;
     c->req.hdr.blk_cnt = creq->nr_sectors;
-    c->req.hdr.cmd = (rq_data_dir(creq) == READ) ? IDA_READ : IDA_WRITE;
+    c->req.hdr.cmd = (rq_uni_rw_dir(creq) == READ) ? IDA_READ : IDA_WRITE;
     c->type = CMD_RWREQ;
 
     /* Put the request on the tail of the request queue */
@@ -1033,7 +1033,7 @@ static inline void complete_command(cmdlist_t *cmd, int timeout)
     complete_buffers(rq->bio, ok);
 
     if (blk_fs_request(rq)) {
-        const int rw = rq_data_dir(rq);
+        const int rw = rq_rw_dir(rq);
 
         disk_stat_add(rq->rq_disk, sectors[rw], rq->nr_sectors);
     }
drivers/block/floppy.c +3 -6
index 5231ed7..d27b8aa 100644
@@ -2325,7 +2325,7 @@ static void request_done(int uptodate)
         floppy_end_request(req, 1);
         spin_unlock_irqrestore(q->queue_lock, flags);
     } else {
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_uni_rw_dir(req) == WRITE) {
             /* record write error information */
             DRWE->write_errors++;
             if (DRWE->write_errors == 1) {
@@ -2628,15 +2628,12 @@ static int make_raw_rw_request(void)
     raw_cmd->flags = FD_RAW_SPIN | FD_RAW_NEED_DISK | FD_RAW_NEED_DISK |
         FD_RAW_NEED_SEEK;
     raw_cmd->cmd_count = NR_RW;
-    if (rq_data_dir(current_req) == READ) {
+    if (rq_uni_rw_dir(current_req) == READ) {
         raw_cmd->flags |= FD_RAW_READ;
         COMMAND = FM_MODE(_floppy, FD_READ);
-    } else if (rq_data_dir(current_req) == WRITE) {
+    } else {
         raw_cmd->flags |= FD_RAW_WRITE;
         COMMAND = FM_MODE(_floppy, FD_WRITE);
-    } else {
-        DPRINT("make_raw_rw_request: unknown command\n");
-        return 0;
     }
 
     max_sector = _floppy->sect * _floppy->head;
drivers/block/nbd.c +2 -1
index 090796b..411e138 100644
@@ -434,7 +434,7 @@ static void do_nbd_request(request_queue_t * q)
         BUG_ON(lo->magic != LO_MAGIC);
 
         nbd_cmd(req) = NBD_CMD_READ;
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_uni_rw_dir(req) == WRITE) {
             nbd_cmd(req) = NBD_CMD_WRITE;
             if (lo->flags & NBD_READ_ONLY) {
                 printk(KERN_ERR "%s: Write on read-only\n",
@@ -502,6 +502,7 @@ static int nbd_ioctl(struct inode *inode, struct file *file,
     dprintk(DBG_IOCTL, "%s: nbd_ioctl cmd=%s(0x%x) arg=%lu\n",
             lo->disk->disk_name, ioctl_cmd_to_ascii(cmd), cmd, arg);
 
+    blk_rq_init_unqueued_req(&sreq);
     switch (cmd) {
     case NBD_DISCONNECT:
             printk(KERN_INFO "%s: NBD_DISCONNECT\n", lo->disk->disk_name);
drivers/block/paride/pcd.c +1 -1
index c852eed..375499e 100644
@@ -722,7 +722,7 @@ static void do_pcd_request(request_queue_t * q)
         if (!pcd_req)
             return;
 
-        if (rq_data_dir(pcd_req) == READ) {
+        if (rq_dma_dir(pcd_req) == DMA_FROM_DEVICE) {
             struct pcd_unit *cd = pcd_req->rq_disk->private_data;
             if (cd != pcd_current)
                 pcd_bufblk = -1;
drivers/block/paride/pd.c +13 -16
index 31e0148..0db4e8a 100644
@@ -441,21 +441,18 @@ static enum action do_pd_io_start(void)
         return pd_special();
     }
 
-    pd_cmd = rq_data_dir(pd_req);
-    if (pd_cmd == READ || pd_cmd == WRITE) {
-        pd_block = pd_req->sector;
-        pd_count = pd_req->current_nr_sectors;
-        if (pd_block + pd_count > get_capacity(pd_req->rq_disk))
-            return Fail;
-        pd_run = pd_req->nr_sectors;
-        pd_buf = pd_req->buffer;
-        pd_retries = 0;
-        if (pd_cmd == READ)
-            return do_pd_read_start();
-        else
-            return do_pd_write_start();
-    }
-    return Fail;
+    pd_cmd = rq_uni_rw_dir(pd_req);
+    pd_block = pd_req->sector;
+    pd_count = pd_req->current_nr_sectors;
+    if (pd_block + pd_count > get_capacity(pd_req->rq_disk))
+        return Fail;
+    pd_run = pd_req->nr_sectors;
+    pd_buf = pd_req->buffer;
+    pd_retries = 0;
+    if (pd_cmd == READ)
+        return do_pd_read_start();
+    else
+        return do_pd_write_start();
 }
 
 static enum action pd_special(void)
@@ -716,7 +713,7 @@ static int pd_special_command(struct pd_unit *disk,
     struct request rq;
     int err = 0;
 
-    memset(&rq, 0, sizeof(rq));
+    blk_rq_init_unqueued_req(&rq);
     rq.errors = 0;
     rq.rq_disk = disk->gd;
     rq.ref_count = 1;
drivers/block/paride/pf.c +2 -7
index 7cdaa19..47e9bcb 100644
@@ -779,20 +779,15 @@ repeat:
         goto repeat;
     }
 
-    pf_cmd = rq_data_dir(pf_req);
+    pf_cmd = rq_uni_rw_dir(pf_req);
     pf_buf = pf_req->buffer;
     pf_retries = 0;
 
     pf_busy = 1;
     if (pf_cmd == READ)
         pi_do_claimed(pf_current->pi, do_pf_read);
-    else if (pf_cmd == WRITE)
+    else
         pi_do_claimed(pf_current->pi, do_pf_write);
-    else {
-        pf_busy = 0;
-        pf_end_request(0);
-        goto repeat;
-    }
 }
 
 static int pf_next_buf(void)
drivers/block/pktcdvd.c +1 -1
index a4fb703..4c2413b 100644
@@ -758,7 +758,7 @@ static int pkt_generic_packet(struct pktcdvd_device *pd, struct packet_command *
     int ret = 0;
 
     rq = blk_get_request(q, (cgc->data_direction == CGC_DATA_WRITE) ?
-                 WRITE : READ, __GFP_WAIT);
+                 DMA_TO_DEVICE : DMA_FROM_DEVICE, __GFP_WAIT);
 
     if (cgc->buflen) {
         if (blk_rq_map_kern(q, rq, cgc->buffer, cgc->buflen, __GFP_WAIT))
drivers/block/ps2esdi.c +5 -4
index 688a4fb..cf06abd 100644
@@ -506,11 +506,12 @@ static void do_ps2esdi_request(request_queue_t * q)
         return;
     }
 
-    switch (rq_data_dir(req)) {
-    case READ:
+    switch (rq_dma_dir(req)) {
+    case DMA_FROM_DEVICE:
+    case DMA_NONE:
         ps2esdi_readwrite(READ, req);
         break;
-    case WRITE:
+    case DMA_TO_DEVICE:
         ps2esdi_readwrite(WRITE, req);
         break;
     default:
@@ -859,7 +860,7 @@ static void ps2esdi_normal_interrupt_handler(u_int int_ret_code)
     case INT_TRANSFER_REQ:
         ps2esdi_prep_dma(current_req->buffer,
                  current_req->current_nr_sectors,
-            (rq_data_dir(current_req) == READ)
+            (rq_uni_rw_dir(current_req) == READ)
             ? MCA_DMA_MODE_16 | MCA_DMA_MODE_WRITE | MCA_DMA_MODE_XFER
             : MCA_DMA_MODE_16 | MCA_DMA_MODE_READ);
         outb(CTRL_ENABLE_DMA | CTRL_ENABLE_INTR, ESDI_CONTROL);
drivers/block/swim3.c +13 -13
index 1a65979..91eb6f9 100644
@@ -336,7 +336,7 @@ static void start_request(struct floppy_state *fs)
             continue;
         }
 
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_uni_rw_dir(req) == WRITE) {
             if (fs->write_prot < 0)
                 fs->write_prot = swim3_readbit(fs, WRITE_PROT);
             if (fs->write_prot) {
@@ -432,7 +432,7 @@ static inline void setup_transfer(struct floppy_state *fs)
         printk(KERN_ERR "swim3: transfer 0 sectors?\n");
         return;
     }
-    if (rq_data_dir(fd_req) == WRITE)
+    if (rq_uni_rw_dir(fd_req) == WRITE)
         n = 1;
     else {
         n = fs->secpertrack - fs->req_sector + 1;
@@ -445,7 +445,7 @@ static inline void setup_transfer(struct floppy_state *fs)
     out_8(&sw->nsect, n);
     out_8(&sw->gap3, 0);
     out_le32(&dr->cmdptr, virt_to_bus(cp));
-    if (rq_data_dir(fd_req) == WRITE) {
+    if (rq_uni_rw_dir(fd_req) == WRITE) {
         /* Set up 3 dma commands: write preamble, data, postamble */
         init_dma(cp, OUTPUT_MORE, write_preamble, sizeof(write_preamble));
         ++cp;
@@ -460,7 +460,7 @@ static inline void setup_transfer(struct floppy_state *fs)
     out_8(&sw->control_bic, DO_ACTION | WRITE_SECTORS);
     in_8(&sw->error);
     out_8(&sw->control_bic, DO_ACTION | WRITE_SECTORS);
-    if (rq_data_dir(fd_req) == WRITE)
+    if (rq_uni_rw_dir(fd_req) == WRITE)
         out_8(&sw->control_bis, WRITE_SECTORS);
     in_8(&sw->intr);
     out_le32(&dr->control, (RUN << 16) | RUN);
@@ -609,7 +609,7 @@ static void xfer_timeout(unsigned long data)
     out_8(&sw->intr_enable, 0);
     out_8(&sw->control_bic, WRITE_SECTORS | DO_ACTION);
     out_8(&sw->select, RELAX);
-    if (rq_data_dir(fd_req) == WRITE)
+    if (rq_uni_rw_dir(fd_req) == WRITE)
         ++cp;
     if (ld_le16(&cp->xfer_status) != 0)
         s = fs->scount - ((ld_le16(&cp->res_count) + 511) >> 9);
@@ -617,8 +617,8 @@ static void xfer_timeout(unsigned long data)
         s = 0;
     fd_req->sector += s;
     fd_req->current_nr_sectors -= s;
-    printk(KERN_ERR "swim3: timeout %sing sector %ld\n",
-           (rq_data_dir(fd_req)==WRITE? "writ": "read"), (long)fd_req->sector);
+    printk(KERN_ERR "swim3: timeout %s sector %ld\n",
+           dma_dir_to_string(fd_rq->data_dir), (long)fd_req->sector);
     end_request(fd_req, 0);
     fs->state = idle;
     start_request(fs);
@@ -636,8 +636,8 @@ static irqreturn_t swim3_interrupt(int irq, void *dev_id)
     intr = in_8(&sw->intr);
     err = (intr & ERROR_INTR)? in_8(&sw->error): 0;
     if ((intr & ERROR_INTR) && fs->state != do_transfer)
-        printk(KERN_ERR "swim3_interrupt, state=%d, dir=%x, intr=%x, err=%x\n",
-               fs->state, rq_data_dir(fd_req), intr, err);
+        printk(KERN_ERR "swim3_interrupt, state=%d, dir=%d, intr=%x, err=%x\n",
+               fs->state, rq_dma_dir(fd_req), intr, err);
     switch (fs->state) {
     case locating:
         if (intr & SEEN_SECTOR) {
@@ -698,7 +698,7 @@ static irqreturn_t swim3_interrupt(int irq, void *dev_id)
         fs->timeout_pending = 0;
         dr = fs->dma;
         cp = fs->dma_cmd;
-        if (rq_data_dir(fd_req) == WRITE)
+        if (rq_uni_rw_dir(fd_req) == WRITE)
             ++cp;
         /*
          * Check that the main data transfer has finished.
@@ -733,7 +733,7 @@ static irqreturn_t swim3_interrupt(int irq, void *dev_id)
                 act(fs);
             } else {
                 printk("swim3: error %sing block %ld (err=%x)\n",
-                       rq_data_dir(fd_req) == WRITE? "writ": "read",
+                       rq_rw_dir(fd_req) == WRITE? "writ": "read",
                        (long)fd_req->sector, err);
                 end_request(fd_req, 0);
                 fs->state = idle;
@@ -742,8 +742,8 @@ static irqreturn_t swim3_interrupt(int irq, void *dev_id)
             if ((stat & ACTIVE) == 0 || resid != 0) {
                 /* musta been an error */
                 printk(KERN_ERR "swim3: fd dma: stat=%x resid=%d\n", stat, resid);
-                printk(KERN_ERR "  state=%d, dir=%x, intr=%x, err=%x\n",
-                       fs->state, rq_data_dir(fd_req), intr, err);
+                printk(KERN_ERR "  state=%d, dir=%d, intr=%x, err=%x\n",
+                       fs->state, rq_dma_dir(fd_req), intr, err);
                 end_request(fd_req, 0);
                 fs->state = idle;
                 start_request(fs);
drivers/block/sx8.c +3 -3
index 54509eb..61df2a0 100644
@@ -565,7 +565,7 @@ static struct carm_request *carm_get_special(struct carm_host *host)
     if (!crq)
         return NULL;
 
-    rq = blk_get_request(host->oob_q, WRITE /* bogus */, GFP_KERNEL);
+    rq = blk_get_request(host->oob_q, DMA_TO_DEVICE /* bogus */, GFP_KERNEL);
     if (!rq) {
         spin_lock_irqsave(&host->lock, flags);
         carm_put_request(host, crq);
@@ -860,7 +860,7 @@ queue_one_request:
 
     blkdev_dequeue_request(rq);
 
-    if (rq_data_dir(rq) == WRITE) {
+    if (rq_uni_rw_dir(rq) == WRITE) {
         writing = 1;
         pci_dir = PCI_DMA_TODEVICE;
     } else {
@@ -1053,7 +1053,7 @@ static inline void carm_handle_rw(struct carm_host *host,
 
     VPRINTK("ENTER\n");
 
-    if (rq_data_dir(crq->rq) == WRITE)
+    if (rq_uni_rw_dir(crq->rq) == WRITE)
         pci_dir = PCI_DMA_TODEVICE;
     else
         pci_dir = PCI_DMA_FROMDEVICE;
drivers/block/ub.c +2 -6
index 2098eff..c789a37 100644
@@ -709,11 +709,7 @@ static void ub_cmd_build_block(struct ub_dev *sc, struct ub_lun *lun,
     struct request *rq = urq->rq;
     unsigned int block, nblks;
 
-    if (rq_data_dir(rq) == WRITE)
-        cmd->dir = UB_DIR_WRITE;
-    else
-        cmd->dir = UB_DIR_READ;
-
+    cmd->dir = rq_uni_rw_dir(rq) ? UB_DIR_WRITE : UB_DIR_READ;
     cmd->nsg = urq->nsg;
     memcpy(cmd->sgv, urq->sgv, sizeof(struct scatterlist) * cmd->nsg);
 
@@ -747,7 +743,7 @@ static void ub_cmd_build_packet(struct ub_dev *sc, struct ub_lun *lun,
     if (rq->data_len == 0) {
         cmd->dir = UB_DIR_NONE;
     } else {
-        if (rq_data_dir(rq) == WRITE)
+        if (rq_uni_rw_dir(rq) == WRITE)
             cmd->dir = UB_DIR_WRITE;
         else
             cmd->dir = UB_DIR_READ;
drivers/block/viodasd.c +1 -1
index 68592c3..ff960c6 100644
@@ -302,7 +302,7 @@ static int send_request(struct request *req)
 
     start = (u64)req->sector << 9;
 
-    if (rq_data_dir(req) == READ) {
+    if (rq_uni_rw_dir(req) == READ) {
         direction = DMA_FROM_DEVICE;
         viocmd = viomajorsubtype_blockio | vioblockread;
         statindex = 0;
drivers/block/xd.c +2 -2
index 0d97b7e..3a4a377 100644
@@ -308,7 +308,7 @@ static void do_xd_request (request_queue_t * q)
     while ((req = elv_next_request(q)) != NULL) {
         unsigned block = req->sector;
         unsigned count = req->nr_sectors;
-        int rw = rq_data_dir(req);
+        int rw = rq_rw_dir(req);
         XD_INFO *disk = req->rq_disk->private_data;
         int res = 0;
         int retry;
@@ -321,7 +321,7 @@ static void do_xd_request (request_queue_t * q)
             end_request(req, 0);
             continue;
         }
-        if (rw != READ && rw != WRITE) {
+        if (!dma_uni_dir(req->data_dir)) {
             printk("do_xd_request: unknown request\n");
             end_request(req, 0);
             continue;
drivers/block/z2ram.c +1 -1
index 7cc2685..6cc92b3 100644
@@ -89,7 +89,7 @@ static void do_z2_request(request_queue_t *q)
             if (len < size)
                 size = len;
             addr += z2ram_map[ start >> Z2RAM_CHUNKSHIFT ];
-            if (rq_data_dir(req) == READ)
+            if (rq_uni_rw_dir(req) == READ)
                 memcpy(req->buffer, (char *)addr, size);
             else
                 memcpy((char *)addr, req->buffer, size);
drivers/cdrom/cdrom.c +1 -1
index b36f44d..53f383d 100644
@@ -2103,7 +2103,7 @@ static int cdrom_read_cdda_bpc(struct cdrom_device_info *cdi, __u8 __user *ubuf,
     if (!q)
         return -ENXIO;
 
-    rq = blk_get_request(q, READ, GFP_KERNEL);
+    rq = blk_get_request(q, DMA_FROM_DEVICE, GFP_KERNEL);
     if (!rq)
         return -ENOMEM;
 
drivers/cdrom/cdu31a.c +1 -1
index 2157c58..2eb37bf 100644
@@ -1342,7 +1342,7 @@ static void do_cdu31a_request(request_queue_t * q)
             end_request(req, 0);
             continue;
         }
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_rw_dir(req) == WRITE) {
             end_request(req, 0);
             continue;
         }
drivers/cdrom/gscd.c +1 -1
index b3ab6e9..8411f8c 100644
@@ -265,7 +265,7 @@ repeat:
         goto out;
 
     if (req->cmd != READ) {
-        printk("GSCD: bad cmd %u\n", rq_data_dir(req));
+        printk("GSCD: bad cmd %u\n", rq_dma_dir(req));
         end_request(req, 0);
         goto repeat;
     }
drivers/cdrom/sbpcd.c +1 -1
index a1283b1..f345876 100644
@@ -4550,7 +4550,7 @@ static void do_sbpcd_request(request_queue_t * q)
     spin_unlock_irq(q->queue_lock);
 
     down(&ioctl_read_sem);
-    if (rq_data_dir(elv_next_request(q)) != READ)
+    if (rq_rw_dir(elv_next_request(q)) != READ)
     {
         msg(DBG_INF, "bad cmd %d\n", req->cmd[0]);
         goto err_done;
drivers/cdrom/sonycd535.c +1 -1
index f77ada9..3516cc7 100644
@@ -816,7 +816,7 @@ do_cdu535_request(request_queue_t * q)
             end_request(req, 0);
             continue;
         }
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_rw_dir(req) == WRITE) {
             end_request(req, 0);
             continue;
         }
drivers/cdrom/viocd.c +1 -1
index 44cd7b2..9afb9e9 100644
@@ -338,7 +338,7 @@ static int send_request(struct request *req)
 
     BUG_ON(req->nr_phys_segments > 1);
 
-    if (rq_data_dir(req) == READ) {
+    if (rq_uni_rw_dir(req) == READ) {
         direction = DMA_FROM_DEVICE;
         cmd = viomajorsubtype_cdio | viocdread;
     } else {
drivers/ide/arm/icside.c +2 -5
index e2953fc..ff14c3c 100644
@@ -214,10 +214,7 @@ static void icside_build_sglist(ide_drive_t *drive, struct request *rq)
 
     ide_map_sg(drive, rq);
 
-    if (rq_data_dir(rq) == READ)
-        hwif->sg_dma_direction = DMA_FROM_DEVICE;
-    else
-        hwif->sg_dma_direction = DMA_TO_DEVICE;
+    hwif->sg_dma_direction = rq_dma_dir(rq);
 
     hwif->sg_nents = dma_map_sg(state->dev, sg, hwif->sg_nents,
                     hwif->sg_dma_direction);
@@ -392,7 +389,7 @@ static int icside_dma_setup(ide_drive_t *drive)
     struct request *rq = hwif->hwgroup->rq;
     unsigned int dma_mode;
 
-    if (rq_data_dir(rq))
+    if (rq_uni_rw_dir(rq))
         dma_mode = DMA_MODE_WRITE;
     else
         dma_mode = DMA_MODE_READ;
drivers/ide/cris/ide-cris.c +2 -2
index 556455f..090269b 100644
@@ -1060,7 +1060,7 @@ static int cris_dma_setup(ide_drive_t *drive)
 {
     struct request *rq = drive->hwif->hwgroup->rq;
 
-    cris_ide_initialize_dma(!rq_data_dir(rq));
+    cris_ide_initialize_dma(!rq_uni_rw_dir(rq));
     if (cris_ide_build_dmatable (drive)) {
         ide_map_sg(drive, rq);
         return 1;
@@ -1082,7 +1082,7 @@ static void cris_dma_exec_cmd(ide_drive_t *drive, u8 command)
 static void cris_dma_start(ide_drive_t *drive)
 {
     struct request *rq = drive->hwif->hwgroup->rq;
-    int writing = rq_data_dir(rq);
+    int writing = rq_uni_rw_dir(rq);
     int type = TYPE_DMA;
 
     if (drive->current_speed >= XFER_UDMA_0)
drivers/ide/ide-cd.c +8 -5
index 45a928c..0387997 100644
@@ -767,7 +767,7 @@ static int cdrom_decode_status(ide_drive_t *drive, int good_stat, int *stat_ret)
 
         if (sense_key == NOT_READY) {
             /* Tray open. */
-            if (rq_data_dir(rq) == READ) {
+            if (rq_uni_rw_dir(rq) == READ) {
                 cdrom_saw_media_change (drive);
 
                 /* Fail the request. */
@@ -1730,7 +1730,7 @@ static ide_startstop_t cdrom_newpc_intr(ide_drive_t *drive)
     /*
      * check which way to transfer data
      */
-    if (rq_data_dir(rq) == WRITE) {
+    if (rq_uni_rw_dir(rq) == WRITE) {
         /*
          * write to drive
          */
@@ -2021,10 +2021,13 @@ ide_do_rw_cdrom (ide_drive_t *drive, struct request *rq, sector_t block)
             }
             CDROM_CONFIG_FLAGS(drive)->seeking = 0;
         }
-        if ((rq_data_dir(rq) == READ) && IDE_LARGE_SEEK(info->last_block, block, IDECD_SEEK_THRESHOLD) && drive->dsc_overlap) {
+        if ((rq_uni_rw_dir(rq) == READ) &&
+            IDE_LARGE_SEEK(info->last_block, block,
+                IDECD_SEEK_THRESHOLD) &&
+            drive->dsc_overlap) {
             action = cdrom_start_seek(drive, block);
         } else {
-            if (rq_data_dir(rq) == READ)
+            if (rq_uni_rw_dir(rq) == READ)
                 action = cdrom_start_read(drive, block);
             else
                 action = cdrom_start_write(drive, rq);
@@ -3066,7 +3069,7 @@ static int ide_cdrom_prep_fs(request_queue_t *q, struct request *rq)
 
     memset(rq->cmd, 0, sizeof(rq->cmd));
 
-    if (rq_data_dir(rq) == READ)
+    if (rq_uni_rw_dir(rq) == READ)
         rq->cmd[0] = GPCMD_READ_10;
     else
         rq->cmd[0] = GPCMD_WRITE_10;
drivers/ide/ide-disk.c +5 -5
index 37aa6dd..5d66966 100644
@@ -253,7 +253,7 @@ static ide_startstop_t __ide_do_rw_disk(ide_drive_t *drive, struct request *rq,
 
     if (dma) {
         if (!hwif->dma_setup(drive)) {
-            if (rq_data_dir(rq)) {
+            if (rq_uni_rw_dir(rq)) {
                 command = lba48 ? WIN_WRITEDMA_EXT : WIN_WRITEDMA;
                 if (drive->vdma)
                     command = lba48 ? WIN_WRITE_EXT: WIN_WRITE;
@@ -270,7 +270,7 @@ static ide_startstop_t __ide_do_rw_disk(ide_drive_t *drive, struct request *rq,
         ide_init_sg_cmd(drive, rq);
     }
 
-    if (rq_data_dir(rq) == READ) {
+    if (rq_uni_rw_dir(rq) == READ) {
 
         if (drive->mult_count) {
             hwif->data_phase = TASKFILE_MULTI_IN;
@@ -318,8 +318,8 @@ static ide_startstop_t ide_do_rw_disk (ide_drive_t *drive, struct request *rq, s
 
     ledtrig_ide_activity();
 
-    pr_debug("%s: %sing: block=%llu, sectors=%lu, buffer=0x%08lx\n",
-         drive->name, rq_data_dir(rq) == READ ? "read" : "writ",
+    pr_debug("%s: %s: block=%llu, sectors=%lu, buffer=0x%08lx\n",
+         drive->name, dma_dir_to_string(rq->data_dir),
          (unsigned long long)block, rq->nr_sectors,
          (unsigned long)rq->buffer);
 
@@ -713,7 +713,7 @@ static int idedisk_issue_flush(request_queue_t *q, struct gendisk *disk,
     if (!drive->wcache)
         return 0;
 
-    rq = blk_get_request(q, WRITE, __GFP_WAIT);
+    rq = blk_get_request(q, DMA_TO_DEVICE, __GFP_WAIT);
 
     idedisk_prepare_flush(q, rq);
 
drivers/ide/ide-dma.c +2 -2
index fd21308..abedd21 100644
@@ -207,7 +207,7 @@ int ide_build_sglist(ide_drive_t *drive, struct request *rq)
 
     ide_map_sg(drive, rq);
 
-    if (rq_data_dir(rq) == READ)
+    if (rq_uni_rw_dir(rq) == READ)
         hwif->sg_dma_direction = PCI_DMA_FROMDEVICE;
     else
         hwif->sg_dma_direction = PCI_DMA_TODEVICE;
@@ -545,7 +545,7 @@ int ide_dma_setup(ide_drive_t *drive)
     unsigned int reading;
     u8 dma_stat;
 
-    if (rq_data_dir(rq))
+    if (rq_uni_rw_dir(rq))
         reading = 0;
     else
         reading = 1 << 3;
drivers/ide/ide-floppy.c +2 -2
index 57cd21c..dfd1562 100644
@@ -1233,7 +1233,7 @@ static void idefloppy_create_rw_cmd (idefloppy_floppy_t *floppy, idefloppy_pc_t
 {
     int block = sector / floppy->bs_factor;
     int blocks = rq->nr_sectors / floppy->bs_factor;
-    int cmd = rq_data_dir(rq);
+    int cmd = rq_uni_rw_dir(rq);
 
     debug_log("create_rw1%d_cmd: block == %d, blocks == %d\n",
         2 * test_bit (IDEFLOPPY_USE_READ12, &floppy->flags),
@@ -1251,7 +1251,7 @@ static void idefloppy_create_rw_cmd (idefloppy_floppy_t *floppy, idefloppy_pc_t
     pc->callback = &idefloppy_rw_callback;
     pc->rq = rq;
     pc->b_count = cmd == READ ? 0 : rq->bio->bi_size;
-    if (rq->cmd_flags & REQ_RW)
+    if (cmd == WRITE)
         set_bit(PC_WRITING, &pc->flags);
     pc->buffer = NULL;
     pc->request_transfer = pc->buffer_size = blocks * floppy->block_size;
drivers/ide/ide-io.c +3 -2
index 0e02800..0097e51 100644
@@ -516,7 +516,8 @@ static ide_startstop_t ide_ata_error(ide_drive_t *drive, struct request *rq, u8
         }
     }
 
-    if ((stat & DRQ_STAT) && rq_data_dir(rq) == READ && hwif->err_stops_fifo == 0)
+    if ((stat & DRQ_STAT) && rq_uni_rw_dir(rq) == READ &&
+        hwif->err_stops_fifo == 0)
         try_to_flush_leftover_data(drive);
 
     if (rq->errors >= ERROR_MAX || blk_noretry_request(rq)) {
@@ -1706,7 +1707,7 @@ irqreturn_t ide_intr (int irq, void *dev_id)
 
 void ide_init_drive_cmd (struct request *rq)
 {
-    memset(rq, 0, sizeof(*rq));
+    blk_rq_init_unqueued_req(rq);
     rq->cmd_type = REQ_TYPE_ATA_CMD;
     rq->ref_count = 1;
 }
drivers/ide/ide-tape.c +1 -1
index 4e59239..3c33d57 100644
@@ -1775,7 +1775,7 @@ static void idetape_create_request_sense_cmd (idetape_pc_t *pc)
 
 static void idetape_init_rq(struct request *rq, u8 cmd)
 {
-    memset(rq, 0, sizeof(*rq));
+    blk_rq_init_unqueued_req(rq);
     rq->cmd_type = REQ_TYPE_SPECIAL;
     rq->cmd[0] = cmd;
 }
drivers/ide/ide-taskfile.c +3 -3
index 30175c7..158338f 100644
@@ -473,7 +473,7 @@ static int ide_diag_taskfile(ide_drive_t *drive, ide_task_t *args, unsigned long
 {
     struct request rq;
 
-    memset(&rq, 0, sizeof(rq));
+    ide_init_drive_cmd(&rq);
     rq.cmd_type = REQ_TYPE_ATA_TASKFILE;
     rq.buffer = buf;
 
@@ -498,8 +498,8 @@ static int ide_diag_taskfile(ide_drive_t *drive, ide_task_t *args, unsigned long
         rq.hard_nr_sectors = rq.nr_sectors;
         rq.hard_cur_sectors = rq.current_nr_sectors = rq.nr_sectors;
 
-        if (args->command_type == IDE_DRIVE_TASK_RAW_WRITE)
-            rq.cmd_flags |= REQ_RW;
+        rq.data_dir = (args->command_type == IDE_DRIVE_TASK_RAW_WRITE) ?
+            DMA_TO_DEVICE : DMA_FROM_DEVICE;
     }
 
     rq.special = args;
drivers/ide/ide.c +2 -2
index a6f098f..67422df 100644
@@ -1242,7 +1242,7 @@ static int generic_ide_suspend(struct device *dev, pm_message_t mesg)
     if (!(drive->dn % 2))
         ide_acpi_get_timing(hwif);
 
-    memset(&rq, 0, sizeof(rq));
+    ide_init_drive_cmd(&rq);
     memset(&rqpm, 0, sizeof(rqpm));
     memset(&args, 0, sizeof(args));
     rq.cmd_type = REQ_TYPE_PM_SUSPEND;
@@ -1270,7 +1270,7 @@ static int generic_ide_resume(struct device *dev)
 
     ide_acpi_exec_tfs(drive);
 
-    memset(&rq, 0, sizeof(rq));
+    ide_init_drive_cmd(&rq);
     memset(&rqpm, 0, sizeof(rqpm));
     memset(&args, 0, sizeof(args));
     rq.cmd_type = REQ_TYPE_PM_RESUME;
drivers/ide/legacy/hd.c +3 -3
index 45ed035..ca8dd47 100644
@@ -627,13 +627,13 @@ repeat:
         cyl, head, sec, nsect, req->buffer);
 #endif
     if (blk_fs_request(req)) {
-        switch (rq_data_dir(req)) {
-        case READ:
+        switch (rq_dma_dir(req)) {
+        case DMA_FROM_DEVICE:
             hd_out(disk,nsect,sec,head,cyl,WIN_READ,&read_intr);
             if (reset)
                 goto repeat;
             break;
-        case WRITE:
+        case DMA_TO_DEVICE:
             hd_out(disk,nsect,sec,head,cyl,WIN_WRITE,&write_intr);
             if (reset)
                 goto repeat;
drivers/ide/mips/au1xxx-ide.c +2 -5
index d54d9fe..ebf2d9b 100644
@@ -248,10 +248,7 @@ static int auide_build_sglist(ide_drive_t *drive,  struct request *rq)
 
     ide_map_sg(drive, rq);
 
-    if (rq_data_dir(rq) == READ)
-        hwif->sg_dma_direction = DMA_FROM_DEVICE;
-    else
-        hwif->sg_dma_direction = DMA_TO_DEVICE;
+    hwif->sg_dma_direction = rq_dma_dir(rq);
 
     return dma_map_sg(ahwif->dev, sg, hwif->sg_nents,
               hwif->sg_dma_direction);
@@ -267,7 +264,7 @@ static int auide_build_dmatable(ide_drive_t *drive)
     _auide_hwif *ahwif = (_auide_hwif*)hwif->hwif_data;
     struct scatterlist *sg;
 
-    iswrite = (rq_data_dir(rq) == WRITE);
+    iswrite = (rq_uni_rw_dir(rq) == WRITE);
     /* Save for interrupt context */
     ahwif->drive = drive;
 
drivers/ide/pci/alim15x3.c +1 -1
index 83e0aa6..72b3576 100644
@@ -585,7 +585,7 @@ no_dma_set:
 static int ali15x3_dma_setup(ide_drive_t *drive)
 {
     if (m5229_revision < 0xC2 && drive->media != ide_disk) {
-        if (rq_data_dir(drive->hwif->hwgroup->rq))
+        if (rq_uni_rw_dir(drive->hwif->hwgroup->rq))
             return 1;    /* try PIO instead of DMA */
     }
     return ide_dma_setup(drive);
drivers/ide/pci/hpt366.c +1 -1
index 60ecdc2..dd83c41 100644
@@ -908,7 +908,7 @@ static void hpt3xxn_set_clock(ide_hwif_t *hwif, u8 mode)
 
 static void hpt3xxn_rw_disk(ide_drive_t *drive, struct request *rq)
 {
-    hpt3xxn_set_clock(HWIF(drive), rq_data_dir(rq) ? 0x23 : 0x21);
+    hpt3xxn_set_clock(HWIF(drive), rq_uni_rw_dir(rq) ? 0x23 : 0x21);
 }
 
 /*
drivers/ide/pci/pdc202xx_old.c +1 -1
index a7a639f..ddd301a 100644
@@ -357,7 +357,7 @@ static void pdc202xx_old_ide_dma_start(ide_drive_t *drive)
 
         outb(clock | (hwif->channel ? 0x08 : 0x02), high_16 + 0x11);
         word_count = (rq->nr_sectors << 8);
-        word_count = (rq_data_dir(rq) == READ) ?
+        word_count = (rq_uni_rw_dir(rq) == READ) ?
                     word_count | 0x05000000 :
                     word_count | 0x06000000;
         outl(word_count, atapi_reg);
drivers/ide/pci/scc_pata.c +1 -1
index f84bf79..1edfbf6 100644
@@ -398,7 +398,7 @@ static int scc_dma_setup(ide_drive_t *drive)
     unsigned int reading;
     u8 dma_stat;
 
-    if (rq_data_dir(rq))
+    if (rq_uni_rw_dir(rq))
         reading = 0;
     else
         reading = 1 << 3;
drivers/ide/pci/sgiioc4.c +2 -2
index fd09b29..7533d79 100644
@@ -554,7 +554,7 @@ static int sgiioc4_ide_dma_setup(ide_drive_t *drive)
     unsigned int count = 0;
     int ddir;
 
-    if (rq_data_dir(rq))
+    if (rq_uni_rw_dir(rq))
         ddir = PCI_DMA_TODEVICE;
     else
         ddir = PCI_DMA_FROMDEVICE;
@@ -565,7 +565,7 @@ static int sgiioc4_ide_dma_setup(ide_drive_t *drive)
         return 1;
     }
 
-    if (rq_data_dir(rq))
+    if (rq_uni_rw_dir(rq))
         /* Writes TO the IOC4 FROM Main Memory */
         ddir = IOC4_DMA_READ;
     else
drivers/ide/pci/trm290.c +1 -1
index cbb1b11..3c39547 100644
@@ -191,7 +191,7 @@ static int trm290_ide_dma_setup(ide_drive_t *drive)
     struct request *rq = hwif->hwgroup->rq;
     unsigned int count, rw;
 
-    if (rq_data_dir(rq)) {
+    if (rq_uni_rw_dir(rq)) {
 #ifdef TRM290_NO_DMA_WRITES
         /* always use PIO for writes */
         trm290_prepare_drive(drive, 0);    /* select PIO xfer */
drivers/ide/ppc/pmac.c +3 -2
index 071a030..909d43d 100644
@@ -1596,7 +1596,7 @@ pmac_ide_build_dmatable(ide_drive_t *drive, struct request *rq)
     pmac_ide_hwif_t* pmif = (pmac_ide_hwif_t *)hwif->hwif_data;
     volatile struct dbdma_regs __iomem *dma = pmif->dma_regs;
     struct scatterlist *sg;
-    int wr = (rq_data_dir(rq) == WRITE);
+    int wr = (rq_uni_rw_dir(rq) == WRITE);
 
     /* DMA table is already aligned */
     table = (struct dbdma_cmd *) pmif->dma_table_cpu;
@@ -1873,7 +1873,8 @@ pmac_ide_dma_setup(ide_drive_t *drive)
 
     /* Apple adds 60ns to wrDataSetup on reads */
     if (ata4 && (pmif->timings[unit] & TR_66_UDMA_EN)) {
-        writel(pmif->timings[unit] + (!rq_data_dir(rq) ? 0x00800000UL : 0),
+        writel(pmif->timings[unit] +
+            (!rq_uni_rw_dir(rq) ? 0x00800000UL : 0),
             PMAC_IDE_REG(IDE_TIMING_CONFIG));
         (void)readl(PMAC_IDE_REG(IDE_TIMING_CONFIG));
     }
drivers/md/dm-emc.c +1 -1
index 265c467..347c2b6 100644
@@ -103,7 +103,7 @@ static struct request *get_failover_req(struct emc_handler *h,
     struct request_queue *q = bdev_get_queue(bdev);
 
     /* FIXME: Figure out why it fails with GFP_ATOMIC. */
-    rq = blk_get_request(q, WRITE, __GFP_WAIT);
+    rq = blk_get_request(q, DMA_TO_DEVICE, __GFP_WAIT);
     if (!rq) {
         DMERR("get_failover_req: blk_get_request failed");
         return NULL;
drivers/message/i2o/i2o_block.c +4 -4
index b17c4b2..1772620 100644
@@ -342,7 +342,7 @@ static inline int i2o_block_sglist_alloc(struct i2o_controller *c,
     ireq->dev = &c->pdev->dev;
     nents = blk_rq_map_sg(ireq->req->q, ireq->req, ireq->sg_table);
 
-    if (rq_data_dir(ireq->req) == READ)
+    if (rq_uni_rw_dir(ireq->req) == READ)
         direction = PCI_DMA_FROMDEVICE;
     else
         direction = PCI_DMA_TODEVICE;
@@ -362,7 +362,7 @@ static inline void i2o_block_sglist_free(struct i2o_block_request *ireq)
 {
     enum dma_data_direction direction;
 
-    if (rq_data_dir(ireq->req) == READ)
+    if (rq_uni_rw_dir(ireq->req) == READ)
         direction = PCI_DMA_FROMDEVICE;
     else
         direction = PCI_DMA_TODEVICE;
@@ -779,7 +779,7 @@ static int i2o_block_transfer(struct request *req)
 
     mptr = &msg->body[0];
 
-    if (rq_data_dir(req) == READ) {
+    if (rq_uni_rw_dir(req) == READ) {
         cmd = I2O_CMD_BLOCK_READ << 24;
 
         switch (dev->rcache) {
@@ -844,7 +844,7 @@ static int i2o_block_transfer(struct request *req)
          * SIMPLE_TAG
          * RETURN_SENSE_DATA_IN_REPLY_MESSAGE_FRAME
          */
-        if (rq_data_dir(req) == READ) {
+        if (rq_uni_rw_dir(req) == READ) {
             cmd[0] = READ_10;
             scsi_flags = 0x60a0000a;
         } else {
drivers/mmc/mmc_block.c +7 -6
index 86439a0..566d7e5 100644
@@ -248,7 +248,8 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
         if (brq.data.blocks > card->host->max_blk_count)
             brq.data.blocks = card->host->max_blk_count;
 
-        mmc_set_data_timeout(&brq.data, card, rq_data_dir(req) != READ);
+        mmc_set_data_timeout(&brq.data, card,
+                             rq_uni_rw_dir(req) != READ);
 
         /*
          * If the host doesn't support multiple block writes, force
@@ -256,7 +257,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
          * this rule as they support querying the number of
          * successfully written sectors.
          */
-        if (rq_data_dir(req) != READ &&
+        if (rq_uni_rw_dir(req) != READ &&
             !(card->host->caps & MMC_CAP_MULTIWRITE) &&
             !mmc_card_sd(card))
             brq.data.blocks = 1;
@@ -272,7 +273,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
             writecmd = MMC_WRITE_BLOCK;
         }
 
-        if (rq_data_dir(req) == READ) {
+        if (rq_uni_rw_dir(req) == READ) {
             brq.cmd.opcode = readcmd;
             brq.data.flags |= MMC_DATA_READ;
         } else {
@@ -302,7 +303,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
             goto cmd_err;
         }
 
-        if (rq_data_dir(req) != READ) {
+        if (rq_uni_rw_dir(req) != READ) {
             do {
                 int err;
 
@@ -357,7 +358,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
      * For reads we just fail the entire chunk as that should
      * be safe in all cases.
      */
-     if (rq_data_dir(req) != READ && mmc_card_sd(card)) {
+     if (rq_uni_rw_dir(req) != READ && mmc_card_sd(card)) {
         u32 blocks;
         unsigned int bytes;
 
@@ -371,7 +372,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct request *req)
             ret = end_that_request_chunk(req, 1, bytes);
             spin_unlock_irq(&md->lock);
         }
-    } else if (rq_data_dir(req) != READ &&
+    } else if (rq_uni_rw_dir(req) != READ &&
            (card->host->caps & MMC_CAP_MULTIWRITE)) {
         spin_lock_irq(&md->lock);
         ret = end_that_request_chunk(req, 1, brq.data.bytes_xfered);
drivers/mtd/mtd_blkdevs.c +4 -4
index b879a66..5df310e 100644
@@ -53,14 +53,14 @@ static int do_blktrans_request(struct mtd_blktrans_ops *tr,
     if (req->sector + req->current_nr_sectors > get_capacity(req->rq_disk))
         return 0;
 
-    switch(rq_data_dir(req)) {
-    case READ:
+    switch(rq_dma_dir(req)) {
+    case DMA_FROM_DEVICE:
         for (; nsect > 0; nsect--, block++, buf += tr->blksize)
             if (tr->readsect(dev, block, buf))
                 return 0;
         return 1;
 
-    case WRITE:
+    case DMA_TO_DEVICE:
         if (!tr->writesect)
             return 0;
 
@@ -70,7 +70,7 @@ static int do_blktrans_request(struct mtd_blktrans_ops *tr,
         return 1;
 
     default:
-        printk(KERN_NOTICE "Unknown request %u\n", rq_data_dir(req));
+        printk(KERN_NOTICE "Unknown request %u\n", rq_dma_dir(req));
         return 0;
     }
 }
drivers/s390/block/dasd.c +1 -1
index eb5dc62..65ab1b1 100644
@@ -1215,7 +1215,7 @@ __dasd_process_blk_queue(struct dasd_device * device)
         req = elv_next_request(queue);
 
         if (device->features & DASD_FEATURE_READONLY &&
-            rq_data_dir(req) == WRITE) {
+            rq_rw_dir(req) == WRITE) {
             DBF_DEV_EVENT(DBF_ERR, device,
                       "Rejecting write request %p",
                       req);
drivers/s390/block/dasd_diag.c +2 -2
index e810e4a..423debf 100644
@@ -478,9 +478,9 @@ dasd_diag_build_cp(struct dasd_device * device, struct request *req)
     unsigned char rw_cmd;
     int i;
 
-    if (rq_data_dir(req) == READ)
+    if (rq_dma_dir(req) == DMA_FROM_DEVICE)
         rw_cmd = MDSK_READ_REQ;
-    else if (rq_data_dir(req) == WRITE)
+    else if (rq_dma_dir(req) == DMA_TO_DEVICE)
         rw_cmd = MDSK_WRITE_REQ;
     else
         return ERR_PTR(-EINVAL);
drivers/s390/block/dasd_eckd.c +5 -5
index cecab22..e73a161 100644
@@ -1113,9 +1113,9 @@ dasd_eckd_build_cp(struct dasd_device * device, struct request *req)
     int i;
 
     private = (struct dasd_eckd_private *) device->private;
-    if (rq_data_dir(req) == READ)
+    if (rq_dma_dir(req) == DMA_FROM_DEVICE)
         cmd = DASD_ECKD_CCW_READ_MT;
-    else if (rq_data_dir(req) == WRITE)
+    else if (rq_dma_dir(req) == DMA_TO_DEVICE)
         cmd = DASD_ECKD_CCW_WRITE_MT;
     else
         return ERR_PTR(-EINVAL);
@@ -1187,7 +1187,7 @@ dasd_eckd_build_cp(struct dasd_device * device, struct request *req)
         if (dasd_page_cache) {
             char *copy = kmem_cache_alloc(dasd_page_cache,
                               GFP_DMA | __GFP_NOWARN);
-            if (copy && rq_data_dir(req) == WRITE)
+            if (copy && rq_uni_rw_dir(req) == WRITE)
                 memcpy(copy + bv->bv_offset, dst, bv->bv_len);
             if (copy)
                 dst = copy + bv->bv_offset;
@@ -1203,7 +1203,7 @@ dasd_eckd_build_cp(struct dasd_device * device, struct request *req)
                     rcmd |= 0x8;
                     count = dasd_eckd_cdl_reclen(recid);
                     if (count < blksize &&
-                        rq_data_dir(req) == READ)
+                        rq_uni_rw_dir(req) == READ)
                         memset(dst + count, 0xe5,
                                blksize - count);
                 }
@@ -1283,7 +1283,7 @@ dasd_eckd_free_cp(struct dasd_ccw_req *cqr, struct request *req)
                 else
                     cda = (char *)((addr_t) ccw->cda);
                 if (dst != cda) {
-                    if (rq_data_dir(req) == READ)
+                    if (rq_uni_rw_dir(req) == READ)
                         memcpy(dst, cda, bv->bv_len);
                     kmem_cache_free(dasd_page_cache,
                         (void *)((addr_t)cda & PAGE_MASK));
drivers/s390/block/dasd_fba.c +7 -7
index be0909e..35a7bfe 100644
@@ -244,9 +244,9 @@ dasd_fba_build_cp(struct dasd_device * device, struct request *req)
     int i;
 
     private = (struct dasd_fba_private *) device->private;
-    if (rq_data_dir(req) == READ) {
+    if (rq_dma_dir(req) == DMA_FROM_DEVICE) {
         cmd = DASD_FBA_CCW_READ;
-    } else if (rq_data_dir(req) == WRITE) {
+    } else if (rq_dma_dir(req) == DMA_TO_DEVICE) {
         cmd = DASD_FBA_CCW_WRITE;
     } else
         return ERR_PTR(-EINVAL);
@@ -293,7 +293,7 @@ dasd_fba_build_cp(struct dasd_device * device, struct request *req)
         return cqr;
     ccw = cqr->cpaddr;
     /* First ccw is define extent. */
-    define_extent(ccw++, cqr->data, rq_data_dir(req),
+    define_extent(ccw++, cqr->data, rq_uni_rw_dir(req),
               device->bp_block, req->sector, req->nr_sectors);
     /* Build locate_record + read/write ccws. */
     idaws = (unsigned long *) (cqr->data + sizeof(struct DE_fba_data));
@@ -301,7 +301,7 @@ dasd_fba_build_cp(struct dasd_device * device, struct request *req)
     /* Locate record for all blocks for smart devices. */
     if (private->rdc_data.mode.bits.data_chain != 0) {
         ccw[-1].flags |= CCW_FLAG_CC;
-        locate_record(ccw++, LO_data++, rq_data_dir(req), 0, count);
+        locate_record(ccw++, LO_data++, rq_uni_rw_dir(req), 0, count);
     }
     recid = first_rec;
     rq_for_each_bio(bio, req) bio_for_each_segment(bv, bio, i) {
@@ -309,7 +309,7 @@ dasd_fba_build_cp(struct dasd_device * device, struct request *req)
         if (dasd_page_cache) {
             char *copy = kmem_cache_alloc(dasd_page_cache,
                               GFP_DMA | __GFP_NOWARN);
-            if (copy && rq_data_dir(req) == WRITE)
+            if (copy && rq_uni_rw_dir(req) == WRITE)
                 memcpy(copy + bv->bv_offset, dst, bv->bv_len);
             if (copy)
                 dst = copy + bv->bv_offset;
@@ -319,7 +319,7 @@ dasd_fba_build_cp(struct dasd_device * device, struct request *req)
             if (private->rdc_data.mode.bits.data_chain == 0) {
                 ccw[-1].flags |= CCW_FLAG_CC;
                 locate_record(ccw, LO_data++,
-                          rq_data_dir(req),
+                          rq_uni_rw_dir(req),
                           recid - first_rec, 1);
                 ccw->flags = CCW_FLAG_CC;
                 ccw++;
@@ -386,7 +386,7 @@ dasd_fba_free_cp(struct dasd_ccw_req *cqr, struct request *req)
                 else
                     cda = (char *)((addr_t) ccw->cda);
                 if (dst != cda) {
-                    if (rq_data_dir(req) == READ)
+                    if (rq_uni_rw_dir(req) == READ)
                         memcpy(dst, cda, bv->bv_len);
                     kmem_cache_free(dasd_page_cache,
                         (void *)((addr_t)cda & PAGE_MASK));
drivers/s390/char/tape_block.c +1 -1
index dd0ecae..e9a67d0 100644
@@ -174,7 +174,7 @@ tapeblock_requeue(struct work_struct *work) {
         nr_queued < TAPEBLOCK_MIN_REQUEUE
     ) {
         req = elv_next_request(queue);
-        if (rq_data_dir(req) == WRITE) {
+        if (rq_rw_dir(req) == WRITE) {
             DBF_EVENT(1, "TBLOCK: Rejecting write request\n");
             blkdev_dequeue_request(req);
             tapeblock_end_request(req, 0);
drivers/sbus/char/jsflash.c +1 -1
index 512857a..36bd378 100644
@@ -199,7 +199,7 @@ static void jsfd_do_request(request_queue_t *q)
             continue;
         }
 
-        if (rq_data_dir(req) != READ) {
+        if (rq_rw_dir(req) != READ) {
             printk(KERN_ERR "jsfd: write\n");
             end_request(req, 0);
             continue;
drivers/scsi/aic7xxx_old.c +2 -2
index a988d5a..2e77803 100644
@@ -2849,7 +2849,7 @@ aic7xxx_done(struct aic7xxx_host *p, struct aic7xxx_scb *scb)
     int x, i;
 
 
-    if (rq_data_dir(cmd->request) == WRITE)
+    if (rq_uni_rw_dir(cmd->request) == WRITE)
     {
       aic_dev->w_total++;
       ptr = aic_dev->w_bins;
@@ -3858,7 +3858,7 @@ aic7xxx_calculate_residual (struct aic7xxx_host *p, struct aic7xxx_scb *scb)
       {
         printk(INFO_LEAD "Underflow - Wanted %u, %s %u, residual SG "
           "count %d.\n", p->host_no, CTL_OF_SCB(scb), cmd->underflow,
-          (rq_data_dir(cmd->request) == WRITE) ? "wrote" : "read", actual,
+          (rq_rw_dir(cmd->request) == WRITE) ? "wrote" : "read", actual,
           hscb->residual_SG_segment_count);
         printk(INFO_LEAD "status 0x%x.\n", p->host_no, CTL_OF_SCB(scb),
           hscb->target_status);
drivers/scsi/scsi_error.c +2 -1
index 918bb60..e4baab6 100644
@@ -1676,6 +1676,7 @@ scsi_reset_provider(struct scsi_device *dev, int flag)
     unsigned long flags;
     int rtn;
 
+    blk_rq_init_unqueued_req(&req);
     scmd->request = &req;
     memset(&scmd->eh_timeout, 0, sizeof(scmd->eh_timeout));
 
@@ -1688,7 +1689,7 @@ scsi_reset_provider(struct scsi_device *dev, int flag)
 
     scmd->cmd_len            = 0;
 
-    scmd->sc_data_direction        = DMA_BIDIRECTIONAL;
+    scmd->sc_data_direction        = DMA_NONE;
 
     init_timer(&scmd->eh_timeout);
 
drivers/scsi/scsi_lib.c +9 -12
index 9f7482d..2c5bc49 100644
@@ -181,10 +181,9 @@ int scsi_execute(struct scsi_device *sdev, const unsigned char *cmd,
          unsigned char *sense, int timeout, int retries, int flags)
 {
     struct request *req;
-    int write = (data_direction == DMA_TO_DEVICE);
     int ret = DRIVER_ERROR << 24;
 
-    req = blk_get_request(sdev->request_queue, write, __GFP_WAIT);
+    req = blk_get_request(sdev->request_queue, data_direction, __GFP_WAIT);
 
     if (bufflen &&    blk_rq_map_kern(sdev->request_queue, req,
                     buffer, bufflen, __GFP_WAIT))
@@ -259,8 +258,10 @@ static int scsi_merge_bio(struct request *rq, struct bio *bio)
     struct request_queue *q = rq->q;
 
     bio->bi_flags &= ~(1 << BIO_SEG_VALID);
-    if (rq_data_dir(rq) == WRITE)
+    if (rq_dma_dir(rq) == DMA_TO_DEVICE)
         bio->bi_rw |= (1 << BIO_RW);
+    else
+        bio->bi_rw &= ~(1 << BIO_RW);
     blk_queue_bounce(q, &bio);
 
     if (!rq->bio)
@@ -386,13 +387,14 @@ int scsi_execute_async(struct scsi_device *sdev, const unsigned char *cmd,
     struct request *req;
     struct scsi_io_context *sioc;
     int err = 0;
-    int write = (data_direction == DMA_TO_DEVICE);
 
     sioc = kmem_cache_zalloc(scsi_io_context_cache, gfp);
     if (!sioc)
         return DRIVER_ERROR << 24;
 
-    req = blk_get_request(sdev->request_queue, write, gfp);
+    WARN_ON((data_direction == DMA_NONE) && bufflen);
+    WARN_ON((data_direction != DMA_NONE) && !bufflen);
+    req = blk_get_request(sdev->request_queue, data_direction, gfp);
     if (!req)
         goto free_sense;
     req->cmd_type = REQ_TYPE_BLOCK_PC;
@@ -1118,18 +1120,13 @@ static int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
         cmd->request_bufflen = 0;
         cmd->request_buffer = NULL;
         cmd->use_sg = 0;
-        req->buffer = NULL;
+        req->data_dir = DMA_NONE;
     }
 
     BUILD_BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
     memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
     cmd->cmd_len = req->cmd_len;
-    if (!req->data_len)
-        cmd->sc_data_direction = DMA_NONE;
-    else if (rq_data_dir(req) == WRITE)
-        cmd->sc_data_direction = DMA_TO_DEVICE;
-    else
-        cmd->sc_data_direction = DMA_FROM_DEVICE;
+    cmd->sc_data_direction = rq_dma_dir(req);
 
     cmd->transfersize = req->data_len;
     cmd->allowed = req->retries;
drivers/scsi/scsi_tgt_lib.c +10 -19
index d402aff..72cdde1 100644
@@ -80,7 +80,6 @@ struct scsi_cmnd *scsi_host_get_command(struct Scsi_Host *shost,
                     enum dma_data_direction data_dir,
                     gfp_t gfp_mask)
 {
-    int write = (data_dir == DMA_TO_DEVICE);
     struct request *rq;
     struct scsi_cmnd *cmd;
     struct scsi_tgt_cmd *tcmd;
@@ -93,7 +92,7 @@ struct scsi_cmnd *scsi_host_get_command(struct Scsi_Host *shost,
     if (!tcmd)
         goto put_dev;
 
-    rq = blk_get_request(shost->uspace_req_q, write, gfp_mask);
+    rq = blk_get_request(shost->uspace_req_q, data_dir, gfp_mask);
     if (!rq)
         goto free_tcmd;
 
@@ -191,17 +190,8 @@ static void scsi_tgt_cmd_destroy(struct work_struct *work)
         container_of(work, struct scsi_tgt_cmd, work);
     struct scsi_cmnd *cmd = tcmd->rq->special;
 
-    dprintk("cmd %p %d %lu\n", cmd, cmd->sc_data_direction,
-        rq_data_dir(cmd->request));
-    /*
-     * We fix rq->cmd_flags here since when we told bio_map_user
-     * to write vm for WRITE commands, blk_rq_bio_prep set
-     * rq_data_dir the flags to READ.
-     */
-    if (cmd->sc_data_direction == DMA_TO_DEVICE)
-        cmd->request->cmd_flags |= REQ_RW;
-    else
-        cmd->request->cmd_flags &= ~REQ_RW;
+    dprintk("cmd %p %d %d\n", cmd, cmd->sc_data_direction,
+        rq_dma_dir(cmd->request));
 
     scsi_unmap_user_pages(tcmd);
     scsi_host_put_command(scsi_tgt_cmd_to_host(cmd), cmd);
@@ -346,7 +336,7 @@ static void scsi_tgt_cmd_done(struct scsi_cmnd *cmd)
 {
     struct scsi_tgt_cmd *tcmd = cmd->request->end_io_data;
 
-    dprintk("cmd %p %lu\n", cmd, rq_data_dir(cmd->request));
+    dprintk("cmd %p %d\n", cmd, rq_dma_dir(cmd->request));
 
     scsi_tgt_uspace_send_status(cmd, tcmd->tag);
     queue_work(scsi_tgtd, &tcmd->work);
@@ -357,7 +347,7 @@ static int __scsi_tgt_transfer_response(struct scsi_cmnd *cmd)
     struct Scsi_Host *shost = scsi_tgt_cmd_to_host(cmd);
     int err;
 
-    dprintk("cmd %p %lu\n", cmd, rq_data_dir(cmd->request));
+    dprintk("cmd %p %d\n", cmd, rq_dma_dir(cmd->request));
 
     err = shost->hostt->transfer_response(cmd, scsi_tgt_cmd_done);
     switch (err) {
@@ -398,8 +388,8 @@ static int scsi_tgt_init_cmd(struct scsi_cmnd *cmd, gfp_t gfp_mask)
 
     cmd->request_bufflen = rq->data_len;
 
-    dprintk("cmd %p addr %p cnt %d %lu\n", cmd, tcmd->buffer, cmd->use_sg,
-        rq_data_dir(rq));
+    dprintk("cmd %p addr %p cnt %d %d\n", cmd, tcmd->buffer, cmd->use_sg,
+        rq_dma_dir(rq));
     count = blk_rq_map_sg(rq->q, rq, cmd->request_buffer);
     if (likely(count <= cmd->use_sg)) {
         cmd->use_sg = count;
@@ -617,8 +607,9 @@ int scsi_tgt_kspace_exec(int host_no, u64 tag, int result, u32 len,
     }
     cmd = rq->special;
 
-    dprintk("cmd %p result %d len %d bufflen %u %lu %x\n", cmd,
-        result, len, cmd->request_bufflen, rq_data_dir(rq), cmd->cmnd[0]);
+    dprintk("cmd %p result %d len %d bufflen %u %d %x\n", cmd,
+        result, len, cmd->request_bufflen, rq_dma_dir(rq),
+        cmd->cmnd[0]);
 
     if (result == TASK_ABORTED) {
         scsi_tgt_abort_cmd(shost, cmd);
drivers/scsi/sd.c +12 -8
index 5a8f55f..e9e60d7 100644
@@ -432,23 +432,27 @@ static int sd_init_command(struct scsi_cmnd * SCpnt)
             this_count = this_count >> 3;
         }
     }
-    if (rq_data_dir(rq) == WRITE) {
+
+    SCpnt->sc_data_direction = rq_dma_dir(rq);
+    switch (SCpnt->sc_data_direction) {
+    case DMA_TO_DEVICE:
         if (!sdp->writeable) {
             return 0;
         }
         SCpnt->cmnd[0] = WRITE_6;
-        SCpnt->sc_data_direction = DMA_TO_DEVICE;
-    } else if (rq_data_dir(rq) == READ) {
+        break;
+    case DMA_FROM_DEVICE:
         SCpnt->cmnd[0] = READ_6;
-        SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-    } else {
-        printk(KERN_ERR "sd: Unknown command %x\n", rq->cmd_flags);
+        break;
+    default:
+        printk(KERN_ERR "sd: Unknown command %x data_dir %d\n",
+            rq->cmd_flags ,rq_dma_dir(rq));
         return 0;
     }
 
     SCSI_LOG_HLQUEUE(2, printk("%s : %s %d/%ld 512 byte blocks.\n",
-        disk->disk_name, (rq_data_dir(rq) == WRITE) ?
-        "writing" : "reading", this_count, rq->nr_sectors));
+        disk->disk_name, dma_dir_to_string(rq->data_dir),
+        this_count, rq->nr_sectors));
 
     SCpnt->cmnd[1] = 0;
 
drivers/scsi/sg.c +0 -2
index 81e3bc7..46a1f7e 100644
@@ -733,8 +733,6 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
         data_dir = DMA_TO_DEVICE;
         break;
     case SG_DXFER_UNKNOWN:
-        data_dir = DMA_BIDIRECTIONAL;
-        break;
     default:
         data_dir = DMA_NONE;
         break;
drivers/scsi/sr.c +8 -7
index 1857d68..40ade44 100644
@@ -334,16 +334,18 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
         return 0;
     }
 
-    if (rq_data_dir(SCpnt->request) == WRITE) {
+    SCpnt->sc_data_direction = rq_dma_dir(SCpnt->request);
+    switch (SCpnt->sc_data_direction) {
+    case DMA_TO_DEVICE:
         if (!cd->device->writeable)
             return 0;
         SCpnt->cmnd[0] = WRITE_10;
-        SCpnt->sc_data_direction = DMA_TO_DEVICE;
           cd->cdi.media_written = 1;
-    } else if (rq_data_dir(SCpnt->request) == READ) {
+        break;
+    case DMA_FROM_DEVICE:
         SCpnt->cmnd[0] = READ_10;
-        SCpnt->sc_data_direction = DMA_FROM_DEVICE;
-    } else {
+        break;
+    default:
         blk_dump_rq_flags(SCpnt->request, "Unknown sr command");
         return 0;
     }
@@ -377,8 +379,7 @@ static int sr_init_command(struct scsi_cmnd * SCpnt)
 
     SCSI_LOG_HLQUEUE(2, printk("%s : %s %d/%ld 512 byte blocks.\n",
                 cd->cdi.name,
-                (rq_data_dir(SCpnt->request) == WRITE) ?
-                    "writing" : "reading",
+                dma_dir_to_string(SCpnt->request->data_dir),
                 this_count, SCpnt->request->nr_sectors));
 
     SCpnt->cmnd[1] = 0;
drivers/scsi/sun3_NCR5380.c +3 -3
index 98e3fe1..6d18b33 100644
@@ -1206,7 +1206,7 @@ static void NCR5380_dma_complete( struct Scsi_Host *instance )
            HOSTNO, NCR5380_read(BUS_AND_STATUS_REG),
            NCR5380_read(STATUS_REG));
 
-    if((sun3scsi_dma_finish(rq_data_dir(hostdata->connected->request)))) {
+    if((sun3scsi_dma_finish(rq_uni_rw_dir(hostdata->connected->request)))) {
         printk("scsi%d: overrun in UDC counter -- not prepared to deal with this!\n", HOSTNO);
         printk("please e-mail [email protected] with a description of how this\n");
         printk("error was produced.\n");
@@ -2024,7 +2024,7 @@ static void NCR5380_information_transfer (struct Scsi_Host *instance)
         {
             if(blk_fs_request(cmd->request)) {
                 sun3scsi_dma_setup(d, count,
-                           rq_data_dir(cmd->request));
+                           rq_uni_rw_dir(cmd->request));
                 sun3_dma_setup_done = cmd;
             }
         }
@@ -2636,7 +2636,7 @@ static void NCR5380_reselect (struct Scsi_Host *instance)
         /* setup this command for dma if not already */
         if((count > SUN3_DMA_MINSIZE) && (sun3_dma_setup_done != tmp))
         {
-            sun3scsi_dma_setup(d, count, rq_data_dir(tmp->request));
+            sun3scsi_dma_setup(d, count, rq_uni_rw_dir(tmp->request));
             sun3_dma_setup_done = tmp;
         }
 #endif
include/linux/blkdev.h +46 -7

103 lines not on this page · raw message

include/linux/blktrace_api.h +7 -1
index 3680ff9..d9665b1 100644
@@ -161,7 +161,13 @@ static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
                     u32 what)
 {
     struct blk_trace *bt = q->blk_trace;
-    int rw = rq->cmd_flags & 0x03;
+    /* blktrace.c prints them according to bio flags */
+    int rw = (((rq_rw_dir(rq) == WRITE) << BIO_RW) |
+              (((rq->cmd_flags & (REQ_SOFTBARRIER|REQ_HARDBARRIER)) != 0) <<
+               BIO_RW_BARRIER) |
+              (((rq->cmd_flags & REQ_FAILFAST) != 0) << BIO_RW_FAILFAST) |
+              (((rq->cmd_flags & REQ_RW_SYNC) != 0) << BIO_RW_SYNC) |
+              (((rq->cmd_flags & REQ_RW_META) != 0) << BIO_RW_META));
 
     if (likely(!bt))
         return;
include/linux/dma-mapping.h +22 -0
index 9a663c6..0d22fd3 100644
@@ -13,6 +13,28 @@ enum dma_data_direction {
     DMA_NONE = 3,
 };
 
+static inline int dma_write_dir(enum dma_data_direction dir)
+{
+    return (dir == DMA_TO_DEVICE) || (dir == DMA_BIDIRECTIONAL);
+}
+
+static inline int dma_uni_dir(enum dma_data_direction dir)
+{
+    return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
+           (dir == DMA_NONE);
+}
+
+static inline char* dma_dir_to_string(enum dma_data_direction dir)
+{
+    switch(dir){
+    case DMA_BIDIRECTIONAL:   return "bidirectional";
+    case DMA_TO_DEVICE:       return "writing";
+    case DMA_FROM_DEVICE:     return "reading";
+    case DMA_NONE:            return "no-data";
+    default:                  return "invalid";
+    }
+}
+
 #define DMA_64BIT_MASK    0xffffffffffffffffULL
 #define DMA_48BIT_MASK    0x0000ffffffffffffULL
 #define DMA_40BIT_MASK    0x000000ffffffffffULL
include/linux/elevator.h +2 -2
index e88fcbc..c947f71 100644
@@ -20,7 +20,7 @@ typedef void (elevator_add_req_fn) (request_queue_t *, struct request *);
 typedef int (elevator_queue_empty_fn) (request_queue_t *);
 typedef struct request *(elevator_request_list_fn) (request_queue_t *, struct request *);
 typedef void (elevator_completed_req_fn) (request_queue_t *, struct request *);
-typedef int (elevator_may_queue_fn) (request_queue_t *, int);
+typedef int (elevator_may_queue_fn) (request_queue_t *, int, int);
 
 typedef int (elevator_set_req_fn) (request_queue_t *, struct request *, gfp_t);
 typedef void (elevator_put_req_fn) (struct request *);
@@ -111,7 +111,7 @@ extern struct request *elv_former_request(request_queue_t *, struct request *);
 extern struct request *elv_latter_request(request_queue_t *, struct request *);
 extern int elv_register_queue(request_queue_t *q);
 extern void elv_unregister_queue(request_queue_t *q);
-extern int elv_may_queue(request_queue_t *, int);
+extern int elv_may_queue(request_queue_t *, int, int);
 extern void elv_completed_request(request_queue_t *, struct request *);
 extern int elv_set_request(request_queue_t *, struct request *, gfp_t);
 extern void elv_put_request(request_queue_t *, struct request *);
Signature · 1 line
1.5.0.4.402.g8035
#2 lore raw

PATCH 2/4 bidi support: fix req->cmd == INT cases

In reply to Boaz Harrosh

- we have unearthed very old bugs in stale drivers that still used request->cmd as a READ|WRITE int
- these drivers should probably go away...

---
 drivers/acorn/block/fd1772.c |    2 +-
 drivers/acorn/block/mfmhd.c  |    8 ++++----
 drivers/block/amiflop.c      |    2 +-
 drivers/block/nbd.c          |    2 +-
 drivers/cdrom/aztcd.c        |    2 +-
 drivers/cdrom/cm206.c        |    2 +-
 drivers/cdrom/gscd.c         |    2 +-
 drivers/cdrom/mcdx.c         |    2 +-
 drivers/cdrom/optcd.c        |    2 +-
 drivers/cdrom/sjcd.c         |    2 +-
 drivers/ide/legacy/hd.c      |    4 ++--
 11 files changed, 15 insertions(+), 15 deletions(-)
drivers/acorn/block/fd1772.c +1 -1
index 674bf81..1717679 100644
@@ -1246,7 +1246,7 @@ repeat:
     del_timer(&motor_off_timer);
 
     ReqCnt = 0;
-    ReqCmd = CURRENT->cmd;
+    ReqCmd = rq_uni_rw_dir(CURRENT);
     ReqBlock = CURRENT->sector;
     ReqBuffer = CURRENT->buffer;
     setup_req_params(drive);
drivers/acorn/block/mfmhd.c +4 -4
index 689a4c3..50001eb 100644
@@ -439,7 +439,7 @@ static void mfm_rw_intr(void)
        a choice of command end or some data which is ready to be collected */
     /* I think we have to transfer data while the interrupt line is on and its
        not any other type of interrupt */
-    if (CURRENT->cmd == WRITE) {
+    if (rq_uni_rw_dir(CURRENT) == WRITE) {
         extern void hdc63463_writedma(void);
         if ((hdc63463_dataleft <= 0) && (!(mfm_status & STAT_CED))) {
             printk("mfm_rw_intr: Apparent DMA write request when no more to DMA\n");
@@ -799,7 +799,7 @@ static void issue_request(unsigned int block, unsigned int nsect,
     raw_cmd.head = start_head;
     raw_cmd.cylinder = track / p->heads;
     raw_cmd.cmdtype = CURRENT->cmd;
-    raw_cmd.cmdcode = CURRENT->cmd == WRITE ? CMD_WD : CMD_RD;
+    raw_cmd.cmdcode = rq_uni_rw_dir(CURRENT) == WRITE ? CMD_WD : CMD_RD;
     raw_cmd.cmddata[0] = dev + 1;    /* DAG: +1 to get US */
     raw_cmd.cmddata[1] = raw_cmd.head;
     raw_cmd.cmddata[2] = raw_cmd.cylinder >> 8;
@@ -830,7 +830,7 @@ static void issue_request(unsigned int block, unsigned int nsect,
     hdc63463_dataleft = nsect * 256;    /* Better way? */
 
     DBG("mfm%c: %sing: CHS=%d/%d/%d, sectors=%d, buffer=0x%08lx (%p)\n",
-         raw_cmd.dev + 'a', (CURRENT->cmd == READ) ? "read" : "writ",
+         raw_cmd.dev + 'a', dma_dir_to_string(rq_dma_dir(CURRENT)),
                raw_cmd.cylinder,
                raw_cmd.head,
         raw_cmd.sector, nsect, (unsigned long) Copy_buffer, CURRENT);
@@ -917,7 +917,7 @@ static void mfm_request(void)
 
         DBG("mfm_request: block after offset=%d\n", block);
 
-        if (CURRENT->cmd != READ && CURRENT->cmd != WRITE) {
+        if (!dma_uni_dir(rq_dma_dir(CURRENT))) {
             printk("unknown mfm-command %d\n", CURRENT->cmd);
             end_request(CURRENT, 0);
             Busy = 0;
drivers/block/amiflop.c +1 -1
index 54f2fb3..fa0da1f 100644
@@ -1363,7 +1363,7 @@ static void redo_fd_request(void)
 #ifdef DEBUG
         printk("fd: sector %ld + %d requested for %s\n",
                CURRENT->sector,cnt,
-               (CURRENT->cmd==READ)?"read":"write");
+               (rq_uni_rw_dir(CURRENT) == READ) ? "read" : "write");
 #endif
         block = CURRENT->sector + cnt;
         if ((int)block > floppy->blocks) {
drivers/block/nbd.c +1 -1
index 411e138..fc5e1b2 100644
@@ -411,7 +411,7 @@ static void nbd_clear_que(struct nbd_device *lo)
 /*
  * We always wait for result of write, for now. It would be nice to make it optional
  * in future
- * if ((req->cmd == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
+ * if ((rq_uni_rw_dir(req) == WRITE) && (lo->flags & NBD_WRITE_NOCHK))
  *   { printk( "Warning: Ignoring result!\n"); nbd_end_request( req ); }
  */
 
drivers/cdrom/aztcd.c +1 -1
index 1f9fb7a..8ccae77 100644
@@ -229,7 +229,7 @@ static struct request_queue *azt_queue;
 static int current_valid(void)
 {
         return CURRENT &&
-        CURRENT->cmd == READ &&
+        rq_rw_dir(CURRENT) == READ &&
         CURRENT->sector != -1;
 }
 
drivers/cdrom/cm206.c +1 -1
index 2301311..1bdf0b7 100644
@@ -851,7 +851,7 @@ static void do_cm206_request(request_queue_t * q)
         if (!req)
             return;
 
-        if (req->cmd != READ) {
+        if (rq_rw_dir(req) != READ) {
             debug(("Non-read command %d on cdrom\n", req->cmd));
             end_request(req, 0);
             continue;
drivers/cdrom/gscd.c +1 -1
index 8411f8c..d08ebbe 100644
@@ -264,7 +264,7 @@ repeat:
     if (req->sector == -1)
         goto out;
 
-    if (req->cmd != READ) {
+    if (rq_rw_dir(req) != READ) {
         printk("GSCD: bad cmd %u\n", rq_dma_dir(req));
         end_request(req, 0);
         goto repeat;
drivers/cdrom/mcdx.c +1 -1
index f574962..52ecbf9 100644
@@ -596,7 +596,7 @@ static void do_mcdx_request(request_queue_t * q)
     xtrace(REQUEST, "do_request() (%lu + %lu)\n",
            req->sector, req->nr_sectors);
 
-    if (req->cmd != READ) {
+    if (rq_rw_dir(req) != READ) {
         xwarn("do_request(): non-read command to cd!!\n");
         xtrace(REQUEST, "end_request(0): write\n");
         end_request(req, 0);
drivers/cdrom/optcd.c +1 -1
index 3541690..73cc108 100644
@@ -977,7 +977,7 @@ static int update_toc(void)
 static int current_valid(void)
 {
         return CURRENT &&
-        CURRENT->cmd == READ &&
+        rq_rw_dir(CURRENT) == READ &&
         CURRENT->sector != -1;
 }
 
drivers/cdrom/sjcd.c +1 -1
index 5409fca..b1d3aa0 100644
@@ -1064,7 +1064,7 @@ static void sjcd_invalidate_buffers(void)
 static int current_valid(void)
 {
         return CURRENT &&
-        CURRENT->cmd == READ &&
+        rq_rw_dir(CURRENT) == READ &&
         CURRENT->sector != -1;
 }
 
drivers/ide/legacy/hd.c +2 -2
index ca8dd47..fac56a2 100644
@@ -622,8 +622,8 @@ repeat:
     head  = track % disk->head;
     cyl   = track / disk->head;
 #ifdef DEBUG
-    printk("%s: %sing: CHS=%d/%d/%d, sectors=%d, buffer=%p\n",
-        req->rq_disk->disk_name, (req->cmd == READ)?"read":"writ",
+    printk("%s: %s: CHS=%d/%d/%d, sectors=%d, buffer=%p\n",
+        req->rq_disk->disk_name, dma_dir_to_string(rq_dma_dir(req)),
         cyl, head, sec, nsect, req->buffer);
 #endif
     if (blk_fs_request(req)) {
Signature · 1 line
1.5.0.4.402.g8035
#4 lore raw

Re: [PATCH 3/4] bidi support: request_io_part

Quoted 11 lines · Boaz Harrosh

- Extract all I/O members of struct request into a request_io_part member.
- Define API to access the I/O part
- Adjust block layer accordingly.
- Change all users to new API.

---------------------------------------------------

Patch is attached compressed because of size

It looks like this patch is very big and is hard for review/maintenance.

I was thinking of a way it could be divided into small patches but still make it compile and run at each stage/patch for bisects.

It could be done in three stages:
1. Make a dummy API that mimics the new API but still lets old drivers/code compile.
2. Stage 2 - convert driver by driver or group by group to new API. this can be done in an arbitrary number of patches.
3. Final stage. do the actual move of members and implement the new API. At this stage, if any drivers are not converted, (out-of-tree drivers), they will not compile.

Please tell me if you need this done? should I send the all patchset or just this one divided? (Below is a demonstration of 1st and 3rd stages at blkdev.h)

<FIRST_STAGE>

include/linux/blkdev.h +52 -32
index c1121d2..579ee2d 100644
@@ -235,23 +235,6 @@ struct request {
 	unsigned int cmd_flags;
 	enum rq_cmd_type_bits cmd_type;
 
-	/* Maintain bio traversal state for part by part I/O submission.
-	 * hard_* are block layer internals, no driver should touch them!
-	 */
-
-	sector_t sector;		/* next sector to submit */
-	sector_t hard_sector;		/* next sector to complete */
-	unsigned long nr_sectors;	/* no. of sectors left to submit */
-	unsigned long hard_nr_sectors;	/* no. of sectors left to complete */
-	/* no. of sectors left to submit in the current segment */
-	unsigned int current_nr_sectors;
-
-	/* no. of sectors left to complete in the current segment */
-	unsigned int hard_cur_sectors;
-
-	struct bio *bio;
-	struct bio *biotail;
-
 	struct hlist_node hash;	/* merge hash */
 	/*
 	 * The rb_node is only used inside the io scheduler, requests
@@ -273,22 +256,11 @@ struct request {
 	struct gendisk *rq_disk;
 	unsigned long start_time;
 
-	/* Number of scatter-gather DMA addr+len pairs after
-	 * physical address coalescing is performed.
-	 */
-	unsigned short nr_phys_segments;
-
-	/* Number of scatter-gather addr+len pairs after
-	 * physical and DMA remapping hardware coalescing is performed.
-	 * This is the number of scatter-gather entries the driver
-	 * will actually have to deal with after DMA mapping is done.
-	 */
-	unsigned short nr_hw_segments;
-
 	unsigned short ioprio;
 
 	void *special;
-	char *buffer;
+	char *buffer;			/* FIXME: should be Deprecated */
+	void *data;			/* FIXME: should be Deprecated */
 
 	int tag;
 	int errors;
@@ -301,9 +273,7 @@ struct request {
 	unsigned int cmd_len;
 	unsigned char cmd[BLK_MAX_CDB];
 
-	unsigned int data_len;
 	unsigned int sense_len;
-	void *data;
 	void *sense;
 
 	unsigned int timeout;
@@ -314,8 +284,49 @@ struct request {
 	 */
 	rq_end_io_fn *end_io;
 	void *end_io_data;
+
+/*
+ request io members. FIXME: will go later in the patchset into a sub-structure
+*/
+/*	struct request_io_part uni; */
+/* struct request_io_part { */
+	unsigned int data_len;
+
+	/* Maintain bio traversal state for part by part I/O submission.
+	 * hard_* are block layer internals, no driver should touch them!
+	 */
+	sector_t sector;		/* next sector to submit */
+	sector_t hard_sector;		/* next sector to complete */
+	unsigned long nr_sectors;	/* no. of sectors left to submit */
+	unsigned long hard_nr_sectors;	/* no. of sectors left to complete */
+	/* no. of sectors left to submit in the current segment */
+	unsigned int current_nr_sectors;
+
+	/* no. of sectors left to complete in the current segment */
+	unsigned int hard_cur_sectors;
+
+	struct bio *bio;
+	struct bio *biotail;
+
+	/* Number of scatter-gather DMA addr+len pairs after
+	 * physical address coalescing is performed.
+	 */
+	unsigned short nr_phys_segments;
+
+	/* Number of scatter-gather addr+len pairs after
+	 * physical and DMA remapping hardware coalescing is performed.
+	 * This is the number of scatter-gather entries the driver
+	 * will actually have to deal with after DMA mapping is done.
+	 */
+	unsigned short nr_hw_segments;
+/* }; */
 };
 
+/* FIXME: here only for the duration of the patchset.
+   will be removed in last patch
+*/
+#define request_io_part request
+
 /*
  * State information carried for REQ_TYPE_PM_SUSPEND and REQ_TYPE_PM_RESUME
  * requests. Some step values could eventually be made generic.
@@ -589,6 +600,15 @@ static inline const char* rq_dir_to_string(struct request* rq)
 }
 
 /*
+ * access for the apropreate bio and io members
+ */
+static inline struct request_io_part* rq_uni(struct request* req)
+{
+	/* FIXME: will be changed to real implementation in last patch */
+	return req;
+}
+
+/*
  * We regard a request as sync, if it's a READ or a SYNC write.
  */
 #define rq_is_sync(rq)		(rq_rw_dir((rq)) == READ || (rq)->cmd_flags & REQ_RW_SYNC)

</FIRST_STAGE>

<SECOND_STAGE>
- Convert all users file by file or group by group. For example:

drivers/cdrom/cdrom.c +1 -1
index b36f44d..eea101f 100644
@@ -2137,7 +2137,7 @@ static int cdrom_read_cdda_bpc(struct cdrom_device_info *cdi, __u8 __user *ubuf,
 		rq->cmd_len = 12;
 		rq->cmd_type = REQ_TYPE_BLOCK_PC;
 		rq->timeout = 60 * HZ;
-		bio = rq->bio;
+		bio = rq_uni(rq)->bio;
 
 		if (blk_execute_rq(q, cdi->disk, rq, 0)) {
 			struct request_sense *s = rq->sense;

</SECOND_STAGE>

<THIRD STAGE>

include/linux/blkdev.h +44 -48

131 lines not on this page · raw message

</THIRD_STAGE>

#5 lore raw

PATCH 4/4 bidi support: bidirectional request

In reply to Boaz Harrosh

- Instantiate another request_io_part in struct request for bidi_read.
- Define & Implement new API for accessing bidi parts.
- API to Build bidi requests and map to sglists.
- Define new end_that_request_block() function to end a complete request.

---
 block/elevator.c        |    7 +--
 block/ll_rw_blk.c       |  120 ++++++++++++++++++++++++++++++++++++++++-------
 drivers/scsi/scsi_lib.c |    2 +-
 include/linux/blkdev.h  |   56 +++++++++++++++++++++-
 4 files changed, 160 insertions(+), 25 deletions(-)
block/elevator.c +1 -6
index 237f15c..e39ef57 100644
@@ -757,14 +757,9 @@ struct request *elv_next_request(request_queue_t *q)
             rq = NULL;
             break;
         } else if (ret == BLKPREP_KILL) {
-            int nr_bytes = rq_uni(rq)->hard_nr_sectors << 9;
-
-            if (!nr_bytes)
-                nr_bytes = rq_uni(rq)->data_len;
-
             blkdev_dequeue_request(rq);
             rq->cmd_flags |= REQ_QUIET;
-            end_that_request_chunk(rq, 0, nr_bytes);
+            end_that_request_block(rq, 0);
             end_that_request_last(rq, 0);
         } else {
             printk(KERN_ERR "%s: bad return=%d\n", __FUNCTION__,
block/ll_rw_blk.c +103 -17

232 lines not on this page · raw message

drivers/scsi/scsi_lib.c +1 -1
index 5863827..42aefd4 100644
@@ -268,7 +268,7 @@ static int scsi_merge_bio(struct request *rq, struct bio *bio)
 
     if (!req_io->bio)
         blk_rq_bio_prep(q, rq, bio);
-    else if (!ll_back_merge_fn(q, rq, bio))
+    else if (!ll_back_merge_fn(q, rq, bio, rq_dma_dir(rq)))
         return -EINVAL;
     else {
         req_io->biotail->bi_next = bio;
include/linux/blkdev.h +55 -1

86 lines not on this page · raw message

Signature · 1 line
1.5.0.4.402.g8035
#6 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

include/linux/blkdev.h struct request { · line 326

Quoted 10 lines
include/linux/blkdev.h +1 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 22 lines
include/linux/blkdev.h +17 -0
 /*
@@ -600,6 +601,34 @@ static inline struct request_io_part* rq_uni(struct request* req)
     return &req->uni;
 }
 
+static inline struct request_io_part* rq_out(struct request* req)
+{
+    WARN_ON_BIDI_FLAG(req);
+    return &req->uni;
+}
+
+static inline struct request_io_part* rq_in(struct request* req)
+{
+    WARN_ON_BIDI_FLAG(req);
+    if (likely(rq_dma_dir(req) != DMA_BIDIRECTIONAL))
+        return &req->uni;
+
+    if (likely(req->cmd_flags & REQ_BIDI))
+        return &req->bidi_read;
+
+    return &req->uni;
+}

include/linux/blkdev.h static inline struct request_io_part* rq_uni(struct request* req) · line 630

Quoted 10 lines
include/linux/blkdev.h +10 -0
+
+static inline struct request_io_part* rq_io(struct request* req,
+                                            enum dma_data_direction dir)
+{
+    if (dir == DMA_FROM_DEVICE)
+        return rq_in(req);
+
+    WARN_ON( (dir != DMA_TO_DEVICE) && (dir != DMA_NONE) );
+    return &req->uni;
+}

static inline struct request_io_part* rq_io(struct request* req)

{
	return (req is WRITE) ? &req->out : &req->in;
}
#7 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 9 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

Quoted 35 lines
Quoted 23 lines
include/linux/blkdev.h +17 -0
 /*
@@ -600,6 +601,34 @@ static inline struct request_io_part* rq_uni(struct request* req)
     return &req->uni;
 }
 
+static inline struct request_io_part* rq_out(struct request* req)
+{
+    WARN_ON_BIDI_FLAG(req);
+    return &req->uni;
+}
+
+static inline struct request_io_part* rq_in(struct request* req)
+{
+    WARN_ON_BIDI_FLAG(req);
+    if (likely(rq_dma_dir(req) != DMA_BIDIRECTIONAL))
+        return &req->uni;
+
+    if (likely(req->cmd_flags & REQ_BIDI))
+        return &req->bidi_read;
+
+    return &req->uni;
+}

include/linux/blkdev.h static inline struct request_io_part* rq_uni(struct request* req) · line 630

Quoted 10 lines
include/linux/blkdev.h +10 -0
+
+static inline struct request_io_part* rq_io(struct request* req,
+                                            enum dma_data_direction dir)
+{
+    if (dir == DMA_FROM_DEVICE)
+        return rq_in(req);
+
+    WARN_ON( (dir != DMA_TO_DEVICE) && (dir != DMA_NONE) );
+    return &req->uni;
+}

static inline struct request_io_part* rq_io(struct request* req)

Quoted 3 lines
{
	return (req is WRITE) ? &req->out : &req->in;
}

Again I'm all for it. But this is a to deep of a change. Too many things changing at once. If we keep the access functions than it does not matter, we can do it later.

Boaz

#8 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 22 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 9 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

James

#9 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 49 lines · James Bottomley
Quoted 22 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 9 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

And it should definitely be a request type.

Signature · 1 line
Jens Axboe
#10 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 62 lines · Jens Axboe
Quoted 46 lines · James Bottomley
Quoted 20 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

Quoted 7 lines

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

I'm attaching the patch we sent back then for your reference. (for some reason I couldn't find the original post in the any linux-scsi archives)

Regards,

Benny

Support for scsi variable length CDBs and bidirectional commands

==== //depot/pub/linux/block/scsi_ioctl.c#1 - /home/bharrosh/p4.local/pub/linux/block/scsi_ioctl.c ====

block/scsi_ioctl.c +5 -2
diff -Nup /tmp/tmp.12171.0 /home/bharrosh/p4.local/pub/linux/block/scsi_ioctl.c -L a/block/scsi_ioctl.c -L b/block/scsi_ioctl.c
@@ -32,10 +32,13 @@
 #include <scsi/scsi_ioctl.h>
 #include <scsi/scsi_cmnd.h>
 
-/* Command group 3 is reserved and should never be used.  */
+/*
+ * Command group 3 is used by variable length CDBs with
+ * opcode VARLEN_CDB.
+ */
 const unsigned char scsi_command_size[8] =
 {
-	6, 10, 10, 12,
+	6, 10, 10, 16,
 	16, 12, 10, 10
 };
 

==== //depot/pub/linux/drivers/scsi/scsi.c#2 - /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi.c ====

drivers/scsi/scsi.c +11 -5
diff -Nup /tmp/tmp.12171.1 /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi.c -L a/drivers/scsi/scsi.c -L b/drivers/scsi/scsi.c
@@ -107,11 +107,14 @@ const char *const scsi_device_types[MAX_
 	"Optical Device   ",
 	"Medium Changer   ",
 	"Communications   ",
-	"Unknown          ",
-	"Unknown          ",
+	"ASC IT8          ",
+	"ASC IT8          ",
 	"RAID             ",
 	"Enclosure        ",
 	"Direct-Access-RBC",
+	"Optical card     ",
+	"Bridge controller",
+	"Object storage   ",
 };
 EXPORT_SYMBOL(scsi_device_types);
 
@@ -456,6 +459,7 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
 	unsigned long flags = 0;
 	unsigned long timeout;
 	int rtn = 0;
+	int cdb_size;
 
 	/* check if the device is still usable */
 	if (unlikely(cmd->device->sdev_state == SDEV_DEL)) {
@@ -537,9 +541,11 @@ int scsi_dispatch_cmd(struct scsi_cmnd *
 	 * Before we queue this command, check if the command
 	 * length exceeds what the host adapter can handle.
 	 */
-	if (CDB_SIZE(cmd) > cmd->device->host->max_cmd_len) {
-		SCSI_LOG_MLQUEUE(3,
-				printk("queuecommand : command too long.\n"));
+	cdb_size = cmd->varlen_cdb ? cmd->varlen_cdb_len : CDB_SIZE(cmd);
+	if (cdb_size > cmd->device->host->max_cmd_len) {
+		SCSI_LOG_MLQUEUE(0,
+				printk("queuecommand : command too long. cdb_size(%d) host->max_cmd_len(%d)\n",
+				cdb_size, cmd->device->host->max_cmd_len));
 		cmd->result = (DID_ABORT << 16);
 
 		scsi_done(cmd);

==== //depot/pub/linux/drivers/scsi/scsi_debug.c#2 - /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi_debug.c ====

drivers/scsi/scsi_debug.c +4 -1
diff -Nup /tmp/tmp.12171.2 /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi_debug.c -L a/drivers/scsi/scsi_debug.c -L b/drivers/scsi/scsi_debug.c
@@ -1794,8 +1794,11 @@ static int scsi_debug_slave_configure(st
 	if (SCSI_DEBUG_OPT_NOISE & scsi_debug_opts)
 		printk(KERN_INFO "scsi_debug: slave_configure <%u %u %u %u>\n",
 		       sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);
-	if (sdp->host->max_cmd_len != SCSI_DEBUG_MAX_CMD_LEN)
+	if (sdp->host->max_cmd_len < SCSI_DEBUG_MAX_CMD_LEN) {
+		printk(KERN_INFO "scsi_debug: max_cmd_len(%d) < SCSI_DEBUG_MAX_CMD_LEN\n",
+		       sdp->host->max_cmd_len);
 		sdp->host->max_cmd_len = SCSI_DEBUG_MAX_CMD_LEN;
+	}
 	devip = devInfoReg(sdp);
 	sdp->hostdata = devip;
 	if (sdp->host->cmd_per_lun)

==== //depot/pub/linux/drivers/scsi/scsi_lib.c#2 - /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi_lib.c ====

drivers/scsi/scsi_lib.c +266 -49

501 lines not on this page · raw message

==== //depot/pub/linux/drivers/scsi/scsi_scan.c#2 - /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi_scan.c ====

drivers/scsi/scsi_scan.c +1 -0
diff -Nup /tmp/tmp.12171.4 /home/bharrosh/p4.local/pub/linux/drivers/scsi/scsi_scan.c -L a/drivers/scsi/scsi_scan.c -L b/drivers/scsi/scsi_scan.c
@@ -674,6 +674,7 @@ static int scsi_add_lun(struct scsi_devi
 	case TYPE_COMM:
 	case TYPE_RAID:
 	case TYPE_RBC:
+	case TYPE_OSD:
 		sdev->writeable = 1;
 		break;
 	case TYPE_WORM:

==== //depot/pub/linux/include/scsi/scsi.h#1 - /home/bharrosh/p4.local/pub/linux/include/scsi/scsi.h ====

include/scsi/scsi.h +3 -1
diff -Nup /tmp/tmp.12171.5 /home/bharrosh/p4.local/pub/linux/include/scsi/scsi.h -L a/include/scsi/scsi.h -L b/include/scsi/scsi.h
@@ -28,7 +28,7 @@ extern const unsigned char scsi_command_
  *	SCSI device types
  */
 
-#define MAX_SCSI_DEVICE_CODE 15
+#define MAX_SCSI_DEVICE_CODE 18
 extern const char *const scsi_device_types[MAX_SCSI_DEVICE_CODE];
 
 /*
@@ -103,6 +103,7 @@ extern const char *const scsi_device_typ
 #define MODE_SENSE_10         0x5a
 #define PERSISTENT_RESERVE_IN 0x5e
 #define PERSISTENT_RESERVE_OUT 0x5f
+#define VARLEN_CDB            0x7f
 #define REPORT_LUNS           0xa0
 #define MOVE_MEDIUM           0xa5
 #define EXCHANGE_MEDIUM       0xa6
@@ -223,6 +224,7 @@ static inline int scsi_status_is_good(in
 #define TYPE_RAID           0x0c
 #define TYPE_ENCLOSURE      0x0d    /* Enclosure Services Device */
 #define TYPE_RBC	    0x0e
+#define TYPE_OSD            0x11
 #define TYPE_NO_LUN         0x7f
 
 /*

==== //depot/pub/linux/include/scsi/scsi_cmnd.h#2 - /home/bharrosh/p4.local/pub/linux/include/scsi/scsi_cmnd.h ====

include/scsi/scsi_cmnd.h +77 -1

114 lines not on this page · raw message

==== //depot/pub/linux/include/scsi/scsi_device.h#1 - /home/bharrosh/p4.local/pub/linux/include/scsi/scsi_device.h ====

include/scsi/scsi_device.h +19 -0
diff -Nup /tmp/tmp.12171.7 /home/bharrosh/p4.local/pub/linux/include/scsi/scsi_device.h -L a/include/scsi/scsi_device.h -L b/include/scsi/scsi_device.h
@@ -198,6 +198,13 @@ static inline struct scsi_target *scsi_t
 #define starget_printk(prefix, starget, fmt, a...)	\
 	dev_printk(prefix, &(starget)->dev, fmt, ##a)
 
+/* used by APIs as a shorthand for <use_sg, buffer, bufflen> */
+struct scsi_cmnd_buff {
+	unsigned short use_sg;      /* Number of pieces of scatter-gather */
+	void *request_buffer;       /* if use_sg==0 requested buffer else an sg list */
+	unsigned request_bufflen;   /* Actual request size */
+};
+
 extern struct scsi_device *__scsi_add_device(struct Scsi_Host *,
 		uint, uint, uint, void *hostdata);
 extern int scsi_add_device(struct Scsi_Host *host, uint channel,
@@ -297,6 +304,18 @@ extern int scsi_execute_async(struct scs
 			      int timeout, int retries, void *privdata,
 			      void (*done)(void *, char *, int, int),
 			      gfp_t gfp);
+extern int scsi_execute_bidi_async(struct scsi_device *sdev,
+                                   const unsigned char *cmd, int cmd_len, int data_direction,
+                                   struct scsi_cmnd_buff *buff,
+                                   struct scsi_cmnd_buff *bidi_read_buff,
+                                   int timeout, int retries, void *privdata,
+                                   void (*done)(void *, char *, int, int),
+                                   gfp_t gfp);
+extern int scsi_execute_bidi(struct scsi_device *sdev,
+                             const unsigned char *cmd, int cmd_len, int data_direction,
+                             struct scsi_cmnd_buff *buff,
+                             struct scsi_cmnd_buff *bidi_read_buff,
+                             char* sense, int timeout, int retries);
 
 static inline void scsi_device_reprobe(struct scsi_device *sdev)
 {

==== //depot/pub/linux/include/scsi/scsi_host.h#2 - /home/bharrosh/p4.local/pub/linux/include/scsi/scsi_host.h ====

include/scsi/scsi_host.h +3 -5
diff -Nup /tmp/tmp.12171.8 /home/bharrosh/p4.local/pub/linux/include/scsi/scsi_host.h -L a/include/scsi/scsi_host.h -L b/include/scsi/scsi_host.h
@@ -500,13 +500,11 @@ struct Scsi_Host {
 	/*
 	 * The maximum length of SCSI commands that this host can accept.
 	 * Probably 12 for most host adapters, but could be 16 for others.
+	 * or 260 if the driver supports variable length cdbs.
 	 * For drivers that don't set this field, a value of 12 is
-	 * assumed.  I am leaving this as a number rather than a bit
-	 * because you never know what subsequent SCSI standards might do
-	 * (i.e. could there be a 20 byte or a 24-byte command a few years
-	 * down the road?).  
+	 * assumed.
 	 */
-	unsigned char max_cmd_len;
+	unsigned short max_cmd_len;
 
 	int this_id;
 	int can_queue;
#11 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 68 lines · Benny Halevy
Quoted 67 lines · Jens Axboe
Quoted 46 lines · James Bottomley
Quoted 20 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 7 lines
Quoted 2 lines

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests.

Quoted 5 lines

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer.

Signature · 1 line
Jens Axboe
#12 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 88 lines · Jens Axboe
Quoted 67 lines · Benny Halevy
Quoted 66 lines · Jens Axboe
Quoted 46 lines · James Bottomley
Quoted 20 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 6 lines
Quoted 2 lines

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests.

Quoted 5 lines

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

Quoted 4 lines

The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer.

Linked SCSI commands have been obsolete since SPC-4 rev 6 (18 July 2006) after proposal 06-259r1 was accepted. That proposal starts: "The reasons for linked commands have been overtaken by time and events." I haven't see anyone mourning their demise on the t10 reflector.

Mapping two requests to one bidi SCSI command might make error handling more of a challenge.

Doug Gilbert

#13 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 94 lines · Douglas Gilbert
Quoted 88 lines · Jens Axboe
Quoted 67 lines · Benny Halevy
Quoted 66 lines · Jens Axboe
Quoted 46 lines · James Bottomley
Quoted 20 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 6 lines
Quoted 2 lines

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests.

Quoted 5 lines

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

Quoted 4 lines

The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer.

Quoted 5 lines

Linked SCSI commands have been obsolete since SPC-4 rev 6 (18 July 2006) after proposal 06-259r1 was accepted. That proposal starts: "The reasons for linked commands have been overtaken by time and events." I haven't see anyone mourning their demise on the t10 reflector.

This has nothing to do with linked commands as defined in the SCSI spec.

Quoted 2 lines

Mapping two requests to one bidi SCSI command might make error handling more of a challenge.

Then go the other way, a command for each. Not a big deal.

Signature · 1 line
Jens Axboe
#14 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 98 lines · Jens Axboe
Quoted 91 lines · Douglas Gilbert
Quoted 86 lines · Jens Axboe
Quoted 67 lines · Benny Halevy
Quoted 66 lines · Jens Axboe
Quoted 46 lines · James Bottomley
Quoted 20 lines · Boaz Harrosh
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 6 lines
Quoted 2 lines

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests.

Quoted 5 lines

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

Quoted 4 lines

The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer.

Quoted 5 lines

Linked SCSI commands have been obsolete since SPC-4 rev 6 (18 July 2006) after proposal 06-259r1 was accepted. That proposal starts: "The reasons for linked commands have been overtaken by time and events." I haven't see anyone mourning their demise on the t10 reflector.

Quoted 7 lines

This has nothing to do with linked commands as defined in the SCSI spec.

Quoted 2 lines

Mapping two requests to one bidi SCSI command might make error handling more of a challenge.

Then go the other way, a command for each. Not a big deal.

Let's take a stab at it then and see how it goes.

#15 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

In reply to Jens Axboe
Quoted 66 lines · Jens Axboe
Quoted 59 lines · Douglas Gilbert
Quoted 54 lines · Jens Axboe
Quoted 35 lines · Benny Halevy
Quoted 34 lines · Jens Axboe
Quoted 14 lines · James Bottomley

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 6 lines
Quoted 2 lines

And it should definitely be a request type.

I'm a bit confused since what you both suggest is very similar to what we've proposed back in October 2006 and the impression we got was that it will be better to support bidirectional block requests natively (yet to be honest, James, you wanted a linked request all along).

It still has to be implemented natively at the block layer, just differently like described above. So instead of messing all over the block layer adding rq_uni() stuff, just add that struct request pointer to the request structure for the 2nd data phase. You can relatively easy then modify the block layer helpers to support mapping and setup of such requests.

Quoted 5 lines

Before we go on that route again, how do you see the support for bidi at the scsi mid-layer done? Again, we prefer to support that officially using two struct scsi_cmnd_buff instances in struct scsi_cmnd and not as a one-off feature, using special-purpose state and logic (e.g. a linked struct scsi_cmd for the bidi_read sg list).

Quoted 4 lines

The SCSI part is up to James, that can be done as either inside a single scsi command, or as linked scsi commands as well. I don't care too much about that bit, just the block layer parts :-). And the proposed block layer design can be used both ways by the scsi layer.

Quoted 5 lines

Linked SCSI commands have been obsolete since SPC-4 rev 6 (18 July 2006) after proposal 06-259r1 was accepted. That proposal starts: "The reasons for linked commands have been overtaken by time and events." I haven't see anyone mourning their demise on the t10 reflector.

Quoted 7 lines

This has nothing to do with linked commands as defined in the SCSI spec.

Quoted 2 lines

Mapping two requests to one bidi SCSI command might make error handling more of a challenge.

Then go the other way, a command for each. Not a big deal.

Hi Jens, James,

Thanks for your response!

Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain.

The patches take into account Douglas concern as well as Jens's and James.
1. Flags and "direction" are kept the same as before. I have only shifted them around a bit so they can work with bidi semantics as well. It is more of a necessary cleanup of weak code. (Patches 1 && 2). Thanks for the offer of a use of a new REQ_TYPE_XXX, but, as you can see below, it is not needed and bidi can safely be handled by the REQ_TYPE_BLOCK_PC paths.
2. C language has, what are called, nameless struct and union. I have used it to enable the same bidi approach as before but in a way that is absolutely backward code compatible. So the huge patch#3 has Just disappeared. The BIDI API is then implemented, considering the first and second adjustments, in a much similar way as before.

I have tested these patches with IBM OSD driver with bidi-enabled SCSI-ml and iSCSI. All OSD and iSCSI tests pass. The overall adjustments are minor. Since I have basically used the old core bidi code I can say with confidence that I have not lost the stability gained by the testers/developers that are using bidi already.

I would like to summarize on why a second request hanging on the first request is less than optimal solution.
1. A full request is not needed. Only the io members are needed.
2. A request is an expensive resource in the kernel. (Allocation, queuing, locking ...) which is a waste if you need to use bidi.
3. Error handling is a mess. Both in the building and in the recovery of io requests. Especially considering the double layering of SCSI-ml. (With struct scsi_cmnd already hanging on req->special)
4. Lots of other code, not at all touched by this patch, will have to change so they safely ignore the extra brain-dead request.
5. Bugs can always creep into ll_rw_blk.c since it is not clear from the code itself what functions are allowed and safe to use with the second io-only request and what functions are only allowed on the main request. With my approach the division of code is very clear.

Concerning what James said about bidi capability been a property of the Q of only these devices that support it. Yes! Block level should not allow bidi access to devices that do not support it. Otherwise, through bsg, (when it will be available), user-mode can DOS the system by sending bidi commands to legacy devices. How should a device advertise this capability?

Please note that these patches are over 2.6.21-rc5 linux-2.6-block tree and will need to be updated and cleaned for proper submission.

Please every one comment so we can proceed in the direction of the final solution. Pros are as
welcome as Cons ;)

Thanks in advance
Boaz Harrosh

Quoted 1 line

From 73c94d6b7e41523d44e7787617c8a1abb351326f Mon Sep 17 00:00:00 2001

From: Boaz Harrosh <bharrosh@bh-buildlin2.(none)>
Date: Sun, 29 Apr 2007 16:11:11 +0300
Subject: [PATCH] rq_direction - is_sync and rw flags cleanup
- is_sync is it's own bool in call to elev{,ator}_may_queue{,fn}
- set some policy on when rw flag is set
- alloc starts as read (0)
- get_request() or __make_request() will set to write acourding to parameter or bio information

---
 block/as-iosched.c       |    2 +-
 block/cfq-iosched.c      |    6 +++---
 block/elevator.c         |    4 ++--
 block/ll_rw_blk.c        |   39 +++++++++++++--------------------------
 include/linux/elevator.h |    4 ++--
 5 files changed, 21 insertions(+), 34 deletions(-)
block/as-iosched.c +1 -1
index ef12627..824d93e 100644
@@ -1285,7 +1285,7 @@ static void as_work_handler(struct work_struct *work)
 	spin_unlock_irqrestore(q->queue_lock, flags);
 }
 
-static int as_may_queue(request_queue_t *q, int rw)
+static int as_may_queue(request_queue_t *q, int rw, int is_sync)
 {
 	int ret = ELV_MQUEUE_MAY;
 	struct as_data *ad = q->elevator->elevator_data;
block/cfq-iosched.c +3 -3
index b6491c0..1392ee9 100644
@@ -226,7 +226,7 @@ static inline pid_t cfq_queue_pid(struct task_struct *task, int rw, int is_sync)
 	/*
 	 * Use the per-process queue, for read requests and syncronous writes
 	 */
-	if (!(rw & REQ_RW) || is_sync)
+	if (!(rw == WRITE) || is_sync)
 		return task->pid;
 
 	return CFQ_KEY_ASYNC;
@@ -1787,14 +1787,14 @@ static inline int __cfq_may_queue(struct cfq_queue *cfqq)
 	return ELV_MQUEUE_MAY;
 }
 
-static int cfq_may_queue(request_queue_t *q, int rw)
+static int cfq_may_queue(request_queue_t *q, int rw, int is_sync)
 {
 	struct cfq_data *cfqd = q->elevator->elevator_data;
 	struct task_struct *tsk = current;
 	struct cfq_queue *cfqq;
 	unsigned int key;
 
-	key = cfq_queue_pid(tsk, rw, rw & REQ_RW_SYNC);
+	key = cfq_queue_pid(tsk, rw, is_sync);
 
 	/*
 	 * don't force setup of a queue from here, as a call to may_queue
block/elevator.c +2 -2
index 96a00c8..eae857f 100644
@@ -845,12 +845,12 @@ void elv_put_request(request_queue_t *q, struct request *rq)
 		e->ops->elevator_put_req_fn(rq);
 }
 
-int elv_may_queue(request_queue_t *q, int rw)
+int elv_may_queue(request_queue_t *q, int rw, int is_sync)
 {
 	elevator_t *e = q->elevator;
 
 	if (e->ops->elevator_may_queue_fn)
-		return e->ops->elevator_may_queue_fn(q, rw);
+		return e->ops->elevator_may_queue_fn(q, rw, is_sync);
 
 	return ELV_MQUEUE_MAY;
 }
block/ll_rw_blk.c +13 -26
index 3de0695..32daa55 100644
@@ -1958,18 +1958,14 @@ static inline void blk_free_request(request_queue_t *q, struct request *rq)
 }
 
 static struct request *
-blk_alloc_request(request_queue_t *q, int rw, int priv, gfp_t gfp_mask)
+blk_alloc_request(request_queue_t *q, int priv, gfp_t gfp_mask)
 {
 	struct request *rq = mempool_alloc(q->rq.rq_pool, gfp_mask);
 
 	if (!rq)
 		return NULL;
 
-	/*
-	 * first three bits are identical in rq->cmd_flags and bio->bi_rw,
-	 * see bio.h and blkdev.h
-	 */
-	rq->cmd_flags = rw | REQ_ALLOCED;
+	rq->cmd_flags = REQ_ALLOCED;
 
 	if (priv) {
 		if (unlikely(elv_set_request(q, rq, gfp_mask))) {
@@ -2055,16 +2051,17 @@ static void freed_request(request_queue_t *q, int rw, int priv)
  * Returns NULL on failure, with queue_lock held.
  * Returns !NULL on success, with queue_lock *not held*.
  */
-static struct request *get_request(request_queue_t *q, int rw_flags,
-				   struct bio *bio, gfp_t gfp_mask)
+static struct request *get_request(request_queue_t *q, int rw,
+                                   struct bio *bio, gfp_t gfp_mask)
 {
 	struct request *rq = NULL;
 	struct request_list *rl = &q->rq;
 	struct io_context *ioc = NULL;
-	const int rw = rw_flags & 0x01;
 	int may_queue, priv;
+	int is_sync = (rw==READ) || (bio && bio_sync(bio));
+	WARN_ON(bio && (bio_data_dir(bio) != (rw==WRITE)));
 
-	may_queue = elv_may_queue(q, rw_flags);
+	may_queue = elv_may_queue(q, rw, is_sync);
 	if (may_queue == ELV_MQUEUE_NO)
 		goto rq_starved;
 
@@ -2112,7 +2109,7 @@ static struct request *get_request(request_queue_t *q, int rw_flags,
 
 	spin_unlock_irq(q->queue_lock);
 
-	rq = blk_alloc_request(q, rw_flags, priv, gfp_mask);
+	rq = blk_alloc_request(q, priv, gfp_mask);
 	if (unlikely(!rq)) {
 		/*
 		 * Allocation failed presumably due to memory. Undo anything
@@ -2147,6 +2144,7 @@ rq_starved:
 	if (ioc_batching(q, ioc))
 		ioc->nr_batch_requests--;
 	
+	rq->cmd_flags |= (rw==WRITE);
 	rq_init(q, rq);
 
 	blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
@@ -2160,13 +2158,12 @@ out:
  *
  * Called with q->queue_lock held, and returns with it unlocked.
  */
-static struct request *get_request_wait(request_queue_t *q, int rw_flags,
+static struct request *get_request_wait(request_queue_t *q, int rw,
 					struct bio *bio)
 {
-	const int rw = rw_flags & 0x01;
 	struct request *rq;
 
-	rq = get_request(q, rw_flags, bio, GFP_NOIO);
+	rq = get_request(q, rw, bio, GFP_NOIO);
 	while (!rq) {
 		DEFINE_WAIT(wait);
 		struct request_list *rl = &q->rq;
@@ -2174,7 +2171,7 @@ static struct request *get_request_wait(request_queue_t *q, int rw_flags,
 		prepare_to_wait_exclusive(&rl->wait[rw], &wait,
 				TASK_UNINTERRUPTIBLE);
 
-		rq = get_request(q, rw_flags, bio, GFP_NOIO);
+		rq = get_request(q, rw, bio, GFP_NOIO);
 
 		if (!rq) {
 			struct io_context *ioc;
@@ -2908,7 +2905,6 @@ static int __make_request(request_queue_t *q, struct bio *bio)
 	int el_ret, nr_sectors, barrier, err;
 	const unsigned short prio = bio_prio(bio);
 	const int sync = bio_sync(bio);
-	int rw_flags;
 
 	nr_sectors = bio_sectors(bio);
 
@@ -2983,19 +2979,10 @@ static int __make_request(request_queue_t *q, struct bio *bio)
 
 get_rq:
 	/*
-	 * This sync check and mask will be re-done in init_request_from_bio(),
-	 * but we need to set it earlier to expose the sync flag to the
-	 * rq allocator and io schedulers.
-	 */
-	rw_flags = bio_data_dir(bio);
-	if (sync)
-		rw_flags |= REQ_RW_SYNC;
-
-	/*
 	 * Grab a free request. This is might sleep but can not fail.
 	 * Returns with the queue unlocked.
 	 */
-	req = get_request_wait(q, rw_flags, bio);
+	req = get_request_wait(q, bio_data_dir(bio), bio);
 
 	/*
 	 * After dropping the lock and possibly sleeping here, our request
include/linux/elevator.h +2 -2
index e88fcbc..c947f71 100644
@@ -20,7 +20,7 @@ typedef void (elevator_add_req_fn) (request_queue_t *, struct request *);
 typedef int (elevator_queue_empty_fn) (request_queue_t *);
 typedef struct request *(elevator_request_list_fn) (request_queue_t *, struct request *);
 typedef void (elevator_completed_req_fn) (request_queue_t *, struct request *);
-typedef int (elevator_may_queue_fn) (request_queue_t *, int);
+typedef int (elevator_may_queue_fn) (request_queue_t *, int, int);
 
 typedef int (elevator_set_req_fn) (request_queue_t *, struct request *, gfp_t);
 typedef void (elevator_put_req_fn) (struct request *);
@@ -111,7 +111,7 @@ extern struct request *elv_former_request(request_queue_t *, struct request *);
 extern struct request *elv_latter_request(request_queue_t *, struct request *);
 extern int elv_register_queue(request_queue_t *q);
 extern void elv_unregister_queue(request_queue_t *q);
-extern int elv_may_queue(request_queue_t *, int);
+extern int elv_may_queue(request_queue_t *, int, int);
 extern void elv_completed_request(request_queue_t *, struct request *);
 extern int elv_set_request(request_queue_t *, struct request *, gfp_t);
 extern void elv_put_request(request_queue_t *, struct request *);
Signature · 1 line
1.5.0.4.402.g8035
Quoted 1 line

From 8d2b3d084da6d7ff9f7fb817b877c6e1b7759028 Mon Sep 17 00:00:00 2001

From: Boaz Harrosh <bharrosh@bh-buildlin2.(none)>
Date: Sun, 29 Apr 2007 16:18:31 +0300
Subject: [PATCH] rq_direction - direction API and cleanups
- define rq_rw_dir() to extract direction from cmd_flgs and translate to WRITE|READ
- rq_data_dir() will WARN_ON bidi before returning rq_rw_dir()
- rq_dma_dir() translate request state to a dma_data_direction enum
- change some users of rq_data dir() to rq_rw_dir() in ll_rw_blk.c elevator.c and scsi_lib.c
- simplify scsi_lib.c command prep in regard to direction.
- clean wrong use of DMA_BIDIRECTIONAL.
- BIO flags and REQ flags no longer match. Remove comments and do a proper translation between the 2 systems. (Please look in ll_rw_blk.c/blk_rq_bio_prep below if we need more flags)

---
 block/deadline-iosched.c     |    8 +++---
 block/elevator.c             |    5 ++-
 block/ll_rw_blk.c            |   37 +++++++++++++++++++++++---------
 drivers/scsi/scsi_error.c    |    2 +-
 drivers/scsi/scsi_lib.c      |   13 +++++------
 drivers/scsi/sg.c            |    2 -
 include/linux/blkdev.h       |   47 +++++++++++++++++++++++++++++++++++++++--
 include/linux/blktrace_api.h |    8 ++++++-
 8 files changed, 91 insertions(+), 31 deletions(-)
block/deadline-iosched.c +4 -4
index 6d673e9..e605c09 100644
@@ -53,7 +53,7 @@ struct deadline_data {
 
 static void deadline_move_request(struct deadline_data *, struct request *);
 
-#define RQ_RB_ROOT(dd, rq)	(&(dd)->sort_list[rq_data_dir((rq))])
+#define RQ_RB_ROOT(dd, rq)	(&(dd)->sort_list[rq_rw_dir((rq))])
 
 static void
 deadline_add_rq_rb(struct deadline_data *dd, struct request *rq)
@@ -72,7 +72,7 @@ retry:
 static inline void
 deadline_del_rq_rb(struct deadline_data *dd, struct request *rq)
 {
-	const int data_dir = rq_data_dir(rq);
+	const int data_dir = rq_rw_dir(rq);
 
 	if (dd->next_rq[data_dir] == rq) {
 		struct rb_node *rbnext = rb_next(&rq->rb_node);
@@ -92,7 +92,7 @@ static void
 deadline_add_request(struct request_queue *q, struct request *rq)
 {
 	struct deadline_data *dd = q->elevator->elevator_data;
-	const int data_dir = rq_data_dir(rq);
+	const int data_dir = rq_rw_dir(rq);
 
 	deadline_add_rq_rb(dd, rq);
 
@@ -197,7 +197,7 @@ deadline_move_to_dispatch(struct deadline_data *dd, struct request *rq)
 static void
 deadline_move_request(struct deadline_data *dd, struct request *rq)
 {
-	const int data_dir = rq_data_dir(rq);
+	const int data_dir = rq_rw_dir(rq);
 	struct rb_node *rbnext = rb_next(&rq->rb_node);
 
 	dd->next_rq[READ] = NULL;
block/elevator.c +3 -2
index eae857f..18485f0 100644
@@ -76,7 +76,7 @@ inline int elv_rq_merge_ok(struct request *rq, struct bio *bio)
 	/*
 	 * different data direction or already started, don't merge
 	 */
-	if (bio_data_dir(bio) != rq_data_dir(rq))
+	if (bio_data_dir(bio) != rq_rw_dir(rq))
 		return 0;
 
 	/*
@@ -733,7 +733,8 @@ struct request *elv_next_request(request_queue_t *q)
 			blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
 		}
 
-		if (!q->boundary_rq || q->boundary_rq == rq) {
+		if ((!q->boundary_rq || q->boundary_rq == rq) &&
+			!rq_is_bidi(rq)) {
 			q->end_sector = rq_end_sector(rq);
 			q->boundary_rq = NULL;
 		}
block/ll_rw_blk.c +26 -11
index 32daa55..0c78540 100644
@@ -2332,7 +2332,7 @@ static int __blk_rq_map_user(request_queue_t *q, struct request *rq,
 	struct bio *bio, *orig_bio;
 	int reading, ret;
 
-	reading = rq_data_dir(rq) == READ;
+	reading = rq_rw_dir(rq) == READ;
 
 	/*
 	 * if alignment requirement is satisfied, map in user pages for
@@ -2476,7 +2476,7 @@ int blk_rq_map_user_iov(request_queue_t *q, struct request *rq,
 	/* we don't allow misaligned data like bio_map_user() does.  If the
 	 * user is using sg, they're expected to know the alignment constraints
 	 * and respect them accordingly */
-	bio = bio_map_user_iov(q, NULL, iov, iov_count, rq_data_dir(rq)== READ);
+	bio = bio_map_user_iov(q, NULL, iov, iov_count, rq_rw_dir(rq)== READ);
 	if (IS_ERR(bio))
 		return PTR_ERR(bio);
 
@@ -2549,7 +2549,7 @@ int blk_rq_map_kern(request_queue_t *q, struct request *rq, void *kbuf,
 	if (IS_ERR(bio))
 		return PTR_ERR(bio);
 
-	if (rq_data_dir(rq) == WRITE)
+	if (rq_rw_dir(rq) == WRITE)
 		bio->bi_rw |= (1 << BIO_RW);
 
 	blk_rq_bio_prep(q, rq, bio);
@@ -2660,7 +2660,7 @@ EXPORT_SYMBOL(blkdev_issue_flush);
 
 static void drive_stat_acct(struct request *rq, int nr_sectors, int new_io)
 {
-	int rw = rq_data_dir(rq);
+	int rw = rq_rw_dir(rq);
 
 	if (!blk_fs_request(rq) || !rq->rq_disk)
 		return;
@@ -2738,7 +2738,7 @@ void __blk_put_request(request_queue_t *q, struct request *req)
 	 * it didn't come out of our reserved rq pools
 	 */
 	if (req->cmd_flags & REQ_ALLOCED) {
-		int rw = rq_data_dir(req);
+		int rw = rq_rw_dir(req);
 		int priv = req->cmd_flags & REQ_ELVPRIV;
 
 		BUG_ON(!list_empty(&req->queuelist));
@@ -2804,7 +2804,7 @@ static int attempt_merge(request_queue_t *q, struct request *req,
 	if (req->sector + req->nr_sectors != next->sector)
 		return 0;
 
-	if (rq_data_dir(req) != rq_data_dir(next)
+	if (rq_rw_dir(req) != rq_rw_dir(next)
 	    || req->rq_disk != next->rq_disk
 	    || next->special)
 		return 0;
@@ -3333,7 +3333,7 @@ static int __end_that_request_first(struct request *req, int uptodate,
 	if (!blk_pc_request(req))
 		req->errors = 0;
 
-	if (!uptodate) {
+	if (error) {
 		if (blk_fs_request(req) && !(req->cmd_flags & REQ_QUIET))
 			printk("end_request: I/O error, dev %s, sector %llu\n",
 				req->rq_disk ? req->rq_disk->disk_name : "?",
@@ -3341,7 +3341,7 @@ static int __end_that_request_first(struct request *req, int uptodate,
 	}
 
 	if (blk_fs_request(req) && req->rq_disk) {
-		const int rw = rq_data_dir(req);
+		const int rw = rq_rw_dir(req);
 
 		disk_stat_add(req->rq_disk, sectors[rw], nr_bytes >> 9);
 	}
@@ -3565,7 +3565,7 @@ void end_that_request_last(struct request *req, int uptodate)
 	 */
 	if (disk && blk_fs_request(req) && req != &req->q->bar_rq) {
 		unsigned long duration = jiffies - req->start_time;
-		const int rw = rq_data_dir(req);
+		const int rw = rq_rw_dir(req);
 
 		__disk_stat_inc(disk, ios[rw]);
 		__disk_stat_add(disk, ticks[rw], duration);
@@ -3593,8 +3593,23 @@ EXPORT_SYMBOL(end_request);
 
 void blk_rq_bio_prep(request_queue_t *q, struct request *rq, struct bio *bio)
 {
-	/* first two bits are identical in rq->cmd_flags and bio->bi_rw */
-	rq->cmd_flags |= (bio->bi_rw & 3);
+	if (bio_data_dir(bio))
+		rq->cmd_flags |= REQ_RW;
+	else
+		rq->cmd_flags &= ~REQ_RW;
+
+	if (bio->bi_rw & (1<<BIO_RW_SYNC))
+		rq->cmd_flags |= REQ_RW_SYNC;
+	else
+		rq->cmd_flags &= ~REQ_RW_SYNC;
+	/* FIXME: what about other flags, should we sync these too? */
+	/*
+	BIO_RW_AHEAD	==> ??
+	BIO_RW_BARRIER	==> REQ_SOFTBARRIER/REQ_HARDBARRIER
+	BIO_RW_FAILFAST	==> REQ_FAILFAST
+	BIO_RW_SYNC	==> REQ_RW_SYNC
+	BIO_RW_META	==> REQ_RW_META
+	*/
 
 	rq->nr_phys_segments = bio_phys_segments(q, bio);
 	rq->nr_hw_segments = bio_hw_segments(q, bio);
drivers/scsi/scsi_error.c +1 -1
index 918bb60..c528ab1 100644
@@ -1688,7 +1688,7 @@ scsi_reset_provider(struct scsi_device *dev, int flag)
 
 	scmd->cmd_len			= 0;
 
-	scmd->sc_data_direction		= DMA_BIDIRECTIONAL;
+	scmd->sc_data_direction		= DMA_NONE;
 
 	init_timer(&scmd->eh_timeout);
 
drivers/scsi/scsi_lib.c +6 -7
index 9f7482d..1fc0471 100644
@@ -259,8 +259,10 @@ static int scsi_merge_bio(struct request *rq, struct bio *bio)
 	struct request_queue *q = rq->q;
 
 	bio->bi_flags &= ~(1 << BIO_SEG_VALID);
-	if (rq_data_dir(rq) == WRITE)
+	if (rq_rw_dir(rq) == WRITE)
 		bio->bi_rw |= (1 << BIO_RW);
+	else
+		bio->bi_rw &= ~(1 << BIO_RW);
 	blk_queue_bounce(q, &bio);
 
 	if (!rq->bio)
@@ -392,6 +394,8 @@ int scsi_execute_async(struct scsi_device *sdev, const unsigned char *cmd,
 	if (!sioc)
 		return DRIVER_ERROR << 24;
 
+	WARN_ON((data_direction == DMA_NONE) && bufflen);
+	WARN_ON((data_direction != DMA_NONE) && !bufflen);
 	req = blk_get_request(sdev->request_queue, write, gfp);
 	if (!req)
 		goto free_sense;
@@ -1124,12 +1128,7 @@ static int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
 	BUILD_BUG_ON(sizeof(req->cmd) > sizeof(cmd->cmnd));
 	memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
 	cmd->cmd_len = req->cmd_len;
-	if (!req->data_len)
-		cmd->sc_data_direction = DMA_NONE;
-	else if (rq_data_dir(req) == WRITE)
-		cmd->sc_data_direction = DMA_TO_DEVICE;
-	else
-		cmd->sc_data_direction = DMA_FROM_DEVICE;
+	cmd->sc_data_direction = rq_dma_dir(req);
 	
 	cmd->transfersize = req->data_len;
 	cmd->allowed = req->retries;
drivers/scsi/sg.c +0 -2
index 81e3bc7..46a1f7e 100644
@@ -733,8 +733,6 @@ sg_common_write(Sg_fd * sfp, Sg_request * srp,
 		data_dir = DMA_TO_DEVICE;
 		break;
 	case SG_DXFER_UNKNOWN:
-		data_dir = DMA_BIDIRECTIONAL;
-		break;
 	default:
 		data_dir = DMA_NONE;
 		break;
include/linux/blkdev.h +44 -3

69 lines not on this page · raw message

include/linux/blktrace_api.h +7 -1
index 3680ff9..d9665b1 100644
@@ -161,7 +161,13 @@ static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
 				    u32 what)
 {
 	struct blk_trace *bt = q->blk_trace;
-	int rw = rq->cmd_flags & 0x03;
+	/* blktrace.c prints them according to bio flags */
+	int rw = (((rq_rw_dir(rq) == WRITE) << BIO_RW) |
+	          (((rq->cmd_flags & (REQ_SOFTBARRIER|REQ_HARDBARRIER)) != 0) <<
+	           BIO_RW_BARRIER) |
+	          (((rq->cmd_flags & REQ_FAILFAST) != 0) << BIO_RW_FAILFAST) |
+	          (((rq->cmd_flags & REQ_RW_SYNC) != 0) << BIO_RW_SYNC) |
+	          (((rq->cmd_flags & REQ_RW_META) != 0) << BIO_RW_META));
 
 	if (likely(!bt))
 		return;
Signature · 1 line
1.5.0.4.402.g8035
Quoted 1 line

From 7aeec62fe483359289aad9286f8dda149f2ce0d4 Mon Sep 17 00:00:00 2001

From: Boaz Harrosh <bharrosh@bh-buildlin2.(none)>
Date: Tue, 1 May 2007 21:09:50 +0300
Subject: [PATCH] block bidi support
- seperate request io members into a substructure (but in a backward compatible way) and add a second set of members for bidi_read.
- Add some bidi helpers to work on a bidi request:
rq_in(), rq_out(), rq_io()
blk_rq_bio_prep_bidi()
blk_rq_map_kern_bidi()
blk_rq_map_sg_bidi()
- change ll_back_merge_fn to support bidi / change only user - scsi_lib.c (Both will be removed in a future scsi cleanup)
- Add end_that_request_block that can clean after a bidi request

---
 block/elevator.c        |    7 +--
 block/ll_rw_blk.c       |  214 ++++++++++++++++++++++++++++++++++++-----------
 drivers/scsi/scsi_lib.c |    2 +-
 include/linux/blkdev.h  |  152 ++++++++++++++++++++++++----------
 4 files changed, 276 insertions(+), 99 deletions(-)
block/elevator.c +1 -6
index 18485f0..90f333e 100644
@@ -755,14 +755,9 @@ struct request *elv_next_request(request_queue_t *q)
 			rq = NULL;
 			break;
 		} else if (ret == BLKPREP_KILL) {
-			int nr_bytes = rq->hard_nr_sectors << 9;
-
-			if (!nr_bytes)
-				nr_bytes = rq->data_len;
-
 			blkdev_dequeue_request(rq);
 			rq->cmd_flags |= REQ_QUIET;
-			end_that_request_chunk(rq, 0, nr_bytes);
+			end_that_request_block(rq, 0);
 			end_that_request_last(rq, 0);
 		} else {
 			printk(KERN_ERR "%s: bad return=%d\n", __FUNCTION__,
block/ll_rw_blk.c +166 -48

414 lines not on this page · raw message

drivers/scsi/scsi_lib.c +1 -1
index 1fc0471..5c80712 100644
@@ -267,7 +267,7 @@ static int scsi_merge_bio(struct request *rq, struct bio *bio)
 
 	if (!rq->bio)
 		blk_rq_bio_prep(q, rq, bio);
-	else if (!ll_back_merge_fn(q, rq, bio))
+	else if (!ll_back_merge_fn(q, rq, bio, rq_data_dir(rq)))
 		return -EINVAL;
 	else {
 		rq->biotail->bi_next = bio;
include/linux/blkdev.h +108 -44

226 lines not on this page · raw message

Signature · 1 line
1.5.0.4.402.g8035
#16 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 4 lines · Boaz Harrosh

Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain.

This isn't much of an improvement imo, if any at all. Why didn't you do the ->next_rq approach I suggested? Your patch still makes struct request considerably fatter (30% here, from 280 to 368 bytes on x86-64 from a quick look) for something that will have relatively few uses. And it still has its paws all over the block layer code.

Please just implement the 2nd data phase as a linked request off the first one. I think that approach is both much cleaner from a design perspective, and also much leaner and has zero (well almost, it costs a pointer) impact on the regular read-write paths.

Signature · 1 line
Jens Axboe
#17 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

From: Jens Axboe <[email protected]>
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Tue, 1 May 2007 20:57:20 +0200

Quoted 12 lines · Boaz Harrosh
Quoted 4 lines

Please consider the attached proposal. It is a complete block-level bidi implementation that is, I hope, a middle ground which will keep everyone happy (including Christoph). It is both quite small and not invasive, yet has a full bidi API that is easy to use and maintain.

This isn't much of an improvement imo, if any at all. Why didn't you do the ->next_rq approach I suggested? Your patch still makes struct request considerably fatter (30% here, from 280 to 368 bytes on x86-64 from a quick look) for something that will have relatively few uses. And it still has its paws all over the block layer code.

Quoted 4 lines

Please just implement the 2nd data phase as a linked request off the first one. I think that approach is both much cleaner from a design perspective, and also much leaner and has zero (well almost, it costs a pointer) impact on the regular read-write paths.

I will send a next_rq patch shortly.

#18 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

In reply to Jens Axboe
Quoted 5 lines · Jens Axboe

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Hey, I want a way to issue those (linked requests) from userspace (SG_IO), too. Specifically for use with the new SMART Command Transport (SCT) feature set on modern SATA drives. As well as for a disk recovery utility I'm working on.

Sounds generally useful, that.

#19 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 7 lines · Mark Lord
Quoted 5 lines · Jens Axboe

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

Quoted 7 lines

Hey, I want a way to issue those (linked requests) from userspace (SG_IO), too.
Specifically for use with the new SMART Command Transport (SCT) feature set on modern SATA drives. As well as for a disk recovery utility I'm working on.

Sounds generally useful, that.

Yep, one of the reasons why I like (my :-) proposal as well, we could potentially find other uses for linking commands like that.

Quoted 1 line
Signature · 1 line
Jens Axboe
#20 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

In reply to Jens Axboe

From: Jens Axboe <[email protected]>
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Mon, 30 Apr 2007 13:11:57 +0200

Quoted 65 lines · James Bottomley
Quoted 49 lines · Boaz Harrosh
Quoted 22 lines
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 9 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

Quoted 4 lines

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

This patch tried this approach. It's just for seeing how it works.

I added bidi support to open-iscsi and bsg and tested this patch lightly. I've attached only a patch for the block layer and scsl-ml. You can get all the patches are:

http://www.kernel.org/pub/linux/kernel/people/tomo/bidi

If we go with this approach, we need just minor changes to the block layer. The overloading rq->special approach needs more but it's reasonable too.

I need to add the proper error handling code, which might be a bit tricky, but I think that it will not be so complicated.

Quoted 1 line

And it should definitely be a request type.

I'm not sure about this. I think that bidi can't be a request type to trace bidi pc requests (we have bidi special requests like SMP). I use REQ_BIDI though I've not implemented bidi trace code.

Quoted 1 line

From 7d278323ff8aad86fb82c823538f7ddfb6ded11c Mon Sep 17 00:00:00 2001

From: FUJITA Tomonori <[email protected]>
Date: Wed, 2 May 2007 03:55:56 +0900
Subject: [PATCH] add bidi support

---
 block/ll_rw_blk.c        |    1 +
 drivers/scsi/scsi_lib.c  |   72 +++++++++++++++++++++++++++++++++++++++-------
 include/linux/blkdev.h   |    7 ++++
 include/scsi/scsi_cmnd.h |    9 ++++++
 4 files changed, 78 insertions(+), 11 deletions(-)
block/ll_rw_blk.c +1 -0
index cf8752a..82842d6 100644
@@ -256,6 +256,7 @@ static void rq_init(request_queue_t *q,
 	rq->end_io = NULL;
 	rq->end_io_data = NULL;
 	rq->completion_data = NULL;
+	rq->next_rq = NULL;
 }
 
 /**
drivers/scsi/scsi_lib.c +61 -11

128 lines not on this page · raw message

include/linux/blkdev.h +7 -0
index 83dcd8c..9d3bb4a 100644
@@ -199,6 +199,7 @@ enum rq_flag_bits {
 	__REQ_ALLOCED,		/* request came from our alloc pool */
 	__REQ_RW_META,		/* metadata io request */
 	__REQ_NR_BITS,		/* stops here */
+	__REQ_BIDI,		/* bidirectional io request */
 };
 
 #define REQ_RW		(1 << __REQ_RW)
@@ -219,6 +220,7 @@ #define REQ_ORDERED_COLOR	(1 << __REQ_OR
 #define REQ_RW_SYNC	(1 << __REQ_RW_SYNC)
 #define REQ_ALLOCED	(1 << __REQ_ALLOCED)
 #define REQ_RW_META	(1 << __REQ_RW_META)
+#define REQ_BIDI	(1 << __REQ_BIDI)
 
 #define BLK_MAX_CDB	16
 
@@ -313,6 +315,9 @@ struct request {
 	 */
 	rq_end_io_fn *end_io;
 	void *end_io_data;
+
+	/* for bidi */
+	struct request *next_rq;
 };
 
 /*
@@ -478,6 +483,7 @@ #define QUEUE_FLAG_DEAD		5	/* queue bein
 #define QUEUE_FLAG_REENTER	6	/* Re-entrancy avoidance */
 #define QUEUE_FLAG_PLUGGED	7	/* queue is plugged */
 #define QUEUE_FLAG_ELVSWITCH	8	/* don't use elevator, just do FIFO */
+#define QUEUE_FLAG_BIDI		9	/* bidirectional requests */
 
 enum {
 	/*
@@ -542,6 +548,7 @@ #define blk_pm_request(rq)	\
 #define blk_sorted_rq(rq)	((rq)->cmd_flags & REQ_SORTED)
 #define blk_barrier_rq(rq)	((rq)->cmd_flags & REQ_HARDBARRIER)
 #define blk_fua_rq(rq)		((rq)->cmd_flags & REQ_FUA)
+#define blk_bidi_rq(rq)		((rq)->cmd_flags & REQ_BIDI)
 
 #define list_entry_rq(ptr)	list_entry((ptr), struct request, queuelist)
 
include/scsi/scsi_cmnd.h +9 -0
index a2e0c10..0e259e5 100644
@@ -11,6 +11,12 @@ struct scatterlist;
 struct Scsi_Host;
 struct scsi_device;
 
+struct scsi_data_buffer {
+	unsigned short use_sg;       /* Number of pieces of scatter-gather */
+	unsigned short sglist_len;   /* size of malloc'd scatter-gather list */
+	void *request_buffer;        /* Actual requested buffer */
+	unsigned request_bufflen;    /* Actual request size */
+};
 
 /* embedded in scsi_cmnd */
 struct scsi_pointer {
@@ -117,6 +123,9 @@ #define SCSI_SENSE_BUFFERSIZE 	96
 
 	unsigned char tag;	/* SCSI-II queued command tag */
 	unsigned long pid;	/* Process ID, starts at 0. Unique per host. */
+
+	/* bidi in buffer */
+	struct scsi_data_buffer ext_request_buffer;
 };
 
 extern struct scsi_cmnd *scsi_get_command(struct scsi_device *, gfp_t);
Signature · 1 line
1.4.3.2
#21 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

Quoted 98 lines · FUJITA Tomonori

From: Jens Axboe <[email protected]>
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Mon, 30 Apr 2007 13:11:57 +0200

Quoted 61 lines · James Bottomley
Quoted 46 lines · Boaz Harrosh
Quoted 20 lines
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

Quoted 4 lines

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

This patch tried this approach. It's just for seeing how it works.

I added bidi support to open-iscsi and bsg and tested this patch lightly. I've attached only a patch for the block layer and scsl-ml. You can get all the patches are:

http://www.kernel.org/pub/linux/kernel/people/tomo/bidi

If we go with this approach, we need just minor changes to the block layer. The overloading rq->special approach needs more but it's reasonable too.

I need to add the proper error handling code, which might be a bit tricky, but I think that it will not be so complicated.

Quoted 1 line

And it should definitely be a request type.

I'm not sure about this. I think that bidi can't be a request type to trace bidi pc requests (we have bidi special requests like SMP). I use REQ_BIDI though I've not implemented bidi trace code.

From 7d278323ff8aad86fb82c823538f7ddfb6ded11c Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[email protected]>
Date: Wed, 2 May 2007 03:55:56 +0900
Subject: [PATCH] add bidi support

Quoted 8 lines
---
 block/ll_rw_blk.c        |    1 +
 drivers/scsi/scsi_lib.c  |   72 +++++++++++++++++++++++++++++++++++++++-------
 include/linux/blkdev.h   |    7 ++++
 include/scsi/scsi_cmnd.h |    9 ++++++
 4 files changed, 78 insertions(+), 11 deletions(-)

Well what can I say guys. Just that I told you so.
After 6 month you all agree on my original solution. Back than I wouldn't even dream of touching block layer and struct request. The 2 requests approach seemed perfectly fine. But people laughed that it is maybe good for out-of-tree debugging but I must do a proper support at the request layer. Even then, I say "ok but can we do it very ugly but safe on the side?, not to touch any legacy code." "No!" people say "do one for in one for out". So what should I understand for next time? a "Proper bidi support at the block layer" means we'll let you have a bad named pointer so you don't have to overload req->end_io_data at the scsi-ml level. Thanks I could use req->data for that.

Tomo's code is a perfectly valid approach, but it is certainly not finished. I have some comments and questions below.
If anyone cares I put up a patcheset that I've tested to be stable. it is here:
http://www.bhalevy.com/open-osd/download/double_request_bidi/

1. I'm not very experienced with blk_map_user but there is some asymmetry at SCSI-ml between handling of the first WRITE request and second READ request. At scsi_end_request() there is the end_that_request_chunk() calls. Now from my experience
with kernel buffers (I am using sglists through scsi_req_map_sg()) not calling end_that_request_chunk() on the second request will leak the BIOs. Maybe blk_{,un}map_user() does not care I'm not sure. In my SCSI-ml patch I have hacked up a scsi_end_request_block() to free the BIOs unconditionally, since it is what I want to do. But calling end_that_request_chunk() with the right size should also do the trick. Also at scsi_release_buffers() you better NULL the pointers and check for not NULL as scsi_release_buffers() can be called multiple times now, and on half prepared commands, in the error handling paths. (See my patch: 0002-scsi-midlayer-bidirectional-commands.patch)

2. At struct request the blk_bidi_rq() should just be:
#define blk_bidi_rq(rq) ((rq)->next_rq != NULL)
The flag gives us nothing but an extra BUG_ON. In fact we don't need the flag at all.
And the name next_rq? are we intending to have a chain of these? What's bad with plain bidi_read?

3. On the other hand we need a new flag REQ_IO_ONLY, to stick on the Second READ request. So block layer can avoid doing any extra work on IO_ONLY requests. For now it does not matter since BIDI devices like OSD do not get any regular FS traffic. But when they will, the Second READ request might confuse the elevator handling.
(See: 0003-out-of-tree-block-bidi-debugging.patch for what I mean)

Right now I'm not sure how to proceed. You can see my current patchset. if any of it you like it's there. If any of it you don't like I can change them. Any questions I will answer But I think I'll go crawl under a rock for a while before I make a fool of myself... oops is that to late?;)

Boaz

#22 lore raw

Re: [PATCH 4/4] bidi support: bidirectional request

From: Boaz Harrosh <[email protected]>
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Thu, 03 May 2007 20:42:44 +0300

Quoted 121 lines
Quoted 98 lines · FUJITA Tomonori

From: Jens Axboe <[email protected]>
Subject: Re: [PATCH 4/4] bidi support: bidirectional request
Date: Mon, 30 Apr 2007 13:11:57 +0200

Quoted 61 lines · James Bottomley
Quoted 46 lines · Boaz Harrosh
Quoted 20 lines
Quoted 11 lines · FUJITA Tomonori

From: Boaz Harrosh <[email protected]>
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300

Quoted 7 lines
include/linux/blkdev.h +0 -0
index 645d24b..16a02ee 100644
@@ -322,6 +322,7 @@ struct request {
     void *end_io_data;
 
Quoted 8 lines

include/linux/blkdev.h struct request { · line 326

Quoted 3 lines
include/linux/blkdev.h +1 -0
     struct request_io_part uni;
+    struct request_io_part bidi_read;
 };

Would be more straightforward to have:

struct request_io_part in;
struct request_io_part out;

Quoted 11 lines

Yes I wish I could do that. For bidi supporting drivers this is the most logical. But for the 99.9% of uni-directional drivers, calling rq_uni(), and being some what on the hotish paths, this means we will need a pointer to a uni request_io_part. This is bad because:
1st- There is no defined stage in a request life where to definitely set that pointer,
specially in the preparation stages.
2nd- hacks like scsi_error.c/scsi_send_eh_cmnd() will not work at all. Now this is a
very bad spot already, and I have a short term fix for it in the SCSI-bidi patches (not sent yet) but a more long term solution is needed. Once such hacks are cleaned up we can do what you say. This is exactly why I use the access functions rq_uni/rq_io/rq_in/rq_out and not open code access.

I'm still not really convinced about this approach. The primary job of the block layer is to manage and merge READ and WRITE requests. It serves a beautiful secondary function of queueing for arbitrary requests it doesn't understand (REQ_TYPE_BLOCK_PC or REQ_TYPE_SPECIAL ... or indeed any non REQ_TYPE_FS).

bidirectional requests fall into the latter category (there's nothing really we can do to merge them ... they're just transported by the block layer). The only unusual feature is that they carry two bios. I think the drivers that actually support bidirectional will be a rarity, so it might even be advisable to add it to the queue capability (refuse bidirectional requests at the top rather than perturbing all the drivers to process them).

Quoted 8 lines

So, what about REQ_TYPE_BIDIRECTIONAL rather than REQ_BIDI? That will remove it from the standard path and put it on the special command type path where we can process it specially. Additionally, if you take this approach, you can probably simply chain the second bio through req->special as an additional request in the stream. The only thing that would then need modification would be the dequeue of the block driver (it would have to dequeue both requests and prepare them) and that needs to be done only for drivers handling bidirectional requests.

I agree, I'm really not crazy about shuffling the entire request setup around just for something as exotic as bidirection commands. How about just keeping it simple - have a second request linked off the first one for the second data phase? So keep it completely seperate, not just overload ->special for 2nd bio list.

Quoted 4 lines

So basically just add a struct request pointer, so you can do rq = rq->next_rq or something for the next data phase. I bet this would be a LOT less invasive as well, and we can get by with a few helpers to support it.

This patch tried this approach. It's just for seeing how it works.

I added bidi support to open-iscsi and bsg and tested this patch lightly. I've attached only a patch for the block layer and scsl-ml. You can get all the patches are:

http://www.kernel.org/pub/linux/kernel/people/tomo/bidi

If we go with this approach, we need just minor changes to the block layer. The overloading rq->special approach needs more but it's reasonable too.

I need to add the proper error handling code, which might be a bit tricky, but I think that it will not be so complicated.

Quoted 1 line

And it should definitely be a request type.

I'm not sure about this. I think that bidi can't be a request type to trace bidi pc requests (we have bidi special requests like SMP). I use REQ_BIDI though I've not implemented bidi trace code.

From 7d278323ff8aad86fb82c823538f7ddfb6ded11c Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <[email protected]>
Date: Wed, 2 May 2007 03:55:56 +0900
Subject: [PATCH] add bidi support

Quoted 8 lines
---
 block/ll_rw_blk.c        |    1 +
 drivers/scsi/scsi_lib.c  |   72 +++++++++++++++++++++++++++++++++++++++-------
 include/linux/blkdev.h   |    7 ++++
 include/scsi/scsi_cmnd.h |    9 ++++++
 4 files changed, 78 insertions(+), 11 deletions(-)

Well what can I say guys. Just that I told you so.
After 6 month you all agree on my original solution. Back than I wouldn't even dream of touching block layer and struct request. The 2 requests approach seemed perfectly fine. But people laughed that it is maybe good for out-of-tree debugging but I must do a proper support at the request layer. Even then, I say "ok but can we do it very ugly but safe on the side?, not to touch any legacy code." "No!" people say "do one for in one for out". So what should I understand for next time? a "Proper bidi support at the block layer" means we'll let you have a bad named pointer so you don't have to overload req->end_io_data at the scsi-ml level. Thanks I could use req->data for that.

Quoted 2 lines

Tomo's code is a perfectly valid approach, but it is certainly not finished. I have some comments and questions below.

Yeah, my patchset can't handle errors, partial completions, etc properly. I'll fix the problems and send a new patchset soon.

Quoted 4 lines

If anyone cares I put up a patcheset that I've tested to be stable. it is here:
http://www.bhalevy.com/open-osd/download/double_request_bidi/

Quoted 10 lines

1. I'm not very experienced with blk_map_user but there is some asymmetry at SCSI-ml between handling of the first WRITE request and second READ request. At scsi_end_request() there is the end_that_request_chunk() calls. Now from my experience with kernel buffers (I am using sglists through scsi_req_map_sg()) not calling end_that_request_chunk() on the second request will leak the BIOs. Maybe blk_{,un}map_user() does not care I'm not sure. In my SCSI-ml patch I have hacked up a scsi_end_request_block() to free the BIOs unconditionally, since it is what I want to do. But calling end_that_request_chunk() with the right size should also do the trick.

I think that we need to call end_that_request_chunk properly against the second request.

Quoted 6 lines

2. At struct request the blk_bidi_rq() should just be:
#define blk_bidi_rq(rq) ((rq)->next_rq != NULL)
The flag gives us nothing but an extra BUG_ON. In fact we don't need the flag at all.
And the name next_rq? are we intending to have a chain of these? What's bad with plain bidi_read?

I used the new bidi flag though I thought about ((rq)->next_rq != NULL) since since we might support a chain of requests. Either is ok for me.

Quoted 6 lines

3. On the other hand we need a new flag REQ_IO_ONLY, to stick on the Second READ request. So block layer can avoid doing any extra work on IO_ONLY requests. For now it does not matter since BIDI devices like OSD do not get any regular FS traffic. But when they will, the Second READ request might confuse the elevator handling.

They will? I'm not sure. I think that the block layer just transports bidi requests.

Quoted 1 line

(See: 0003-out-of-tree-block-bidi-debugging.patch for what I mean)

So I don't think that we need to touch the elevator code.

#23 lore raw
In reply to Boaz Harrosh
Quoted 70 lines · Boaz Harrosh

Following are 4 (large) patches for support of bidirectional block I/O in kernel. (not including SCSI-ml or iSCSI)

The submitted work is against linux-2.6-block tree as of 2007/04/15, and will only cleanly apply in succession.

The patches are based on the RFC I sent 3 months ago. They only cover the block layer at this point. I suggest they get included in Morton's tree until they reach the kernel so they can get compiled on all architectures/platforms. There is still a chance that architectures I did not compile were not fully converted. (FWIW, my search for use of struct request members failed to find them). If you find such a case, please send me the file name and I will fix it ASAP.

Patches summary:
1. [PATCH 1/4] bidi support: request dma_data_direction
- Convert REQ_RW bit flag to a dma_data_direction member like in SCSI-ml use.
- removed rq_data_dir() and added other APIs for querying request's direction.
- fix usage of rq_data_dir() and peeking at req->cmd_flags & REQ_RW to using new api.
- clean-up bad usage of DMA_BIDIRECTIONAL and bzero of none-queue requests, to use the new blk_rq_init_unqueued_req()

2. [PATCH 2/4] bidi support: fix req->cmd == INT cases
- Digging into all these old drivers, I have found traces of past life where request->cmd was the command type. This patch fixes some of these places. All drivers touched by this patch are clear indication of drivers that were not used for a while. Should we removed them from Kernel? These Are:
drivers/acorn/block/fd1772.c, drivers/acorn/block/mfmhd.c, drivers/block/nbd.c, drivers/cdrom/aztcd.c, drivers/cdrom/cm206.c drivers/cdrom/gscd.c, drivers/cdrom/mcdx.c, drivers/cdrom/optcd.c drivers/cdrom/sjcd.c, drivers/ide/legacy/hd.c, drivers/block/amiflop.c

2. [PATCH 3/4] bidi support: request_io_part
- extract io related fields in struct request into struct request_io_part in preparation to full bidi support.
- new rq_uni() API to access the sub-structure. (Please read below comment on why an API and not open code the access)
- Convert All users to new API.

3. [PATCH 4/4] bidi support: bidirectional block layer
- add one more request_io_part member for bidi support in struct request.
- add block layer API functions for mapping and accessing bidi data buffers and for ending a block request as a whole (end_that_request_block())

--------------------------------------------------------------------------------------------
Developer comments:

patch 1/4: Borrow from struct scsi_cmnd use of enum dma_data_direction. Further work (in progress) is the removal of the corresponding member from struct scsi_cmnd and converting all users to directly access rq_dma_dir(sc->req).

patch 3/4: The reasons for introducing the rq_uni(req) API rather than directly accessing req->uni are:

* WARN(!bidi_dir(req)) is life saving when developing bidi enabled paths. Once we, bidi users, start to push bidi requests down the kernel paths, we immediately get warned of paths we did not anticipate. Otherwise, they will be very hard to find, and will hurt kernel stability.

* A cleaner and saner future implementation could be in/out members rather than uni/bidi_read. This way the dma_direction member can deprecated and the uni sub- structure can be maintained using a pointer in struct req.
With this API we are free to change the implementation in the future without touching any users of the API. We can also experiment with what's best. Also, with the API it is much easier to convert uni-directional drivers for bidi (look in ll_rw_block.c in patch 4/4).

Quoted 2 lines

* Note, that internal uses inside the block layer access req->uni directly, as they will need to be changed if the implementation of req->{uni, bidi_read} changes.

Boaz,
Recently I have been looking at things from the perspective of a SAS target and thinking about bidi commands. Taking XDWRITEREAD(10) in sbc3r09.pdf (section 5.44) as an example, with DISABLE_WRITE=0, the "device server" in the target should do the following:
a) decode the cdb **
b) read from storage [lba, transfer_length]
c) fetch data_out from initiator [transfer_length] ***
d) XOR data from (b) and (c) and place result in (z)
e) write the data from (c) to storage [lba, transfer_length]
f) send (z) in data_in to initiator [transfer_length]
g) send SCSI completion status to initiator

Logically a) must occur first and g) last. The b) to f) sequence could be repeated (perhaps) by the device server subdividing the transfer_length (i.e. it may not be reasonable for the OS to assume that the data_out transfer will be complete before there is any data_in transfer). With this command (and with most other bidi commands I suspect) there is little opportunity for full duplex data movement within this command (i.e. little or no data associated with this command moving both ways "on the wire" at the same time).

Seen from sgv4 and the initiator we basically set up the resources that the target's device server uses during the execution of that command:
0) cdb [XDWRITEREAD(lba,transfer_length)]
1) data_out buffer ("write" out to device)
2) data_in buffer ("read" in from device)
3) sense buffer (in case of problems)
4) SCSI (and transport) completion status

After setting up 1), 2) and 3), the initiator pushes 0) to the target (lu) and then waits until it is told 4) is finished. The order in which 1) and 2) are used is dictated by the device server in the target. [Pushing 0) and 1) can be partially combined in the ** case, see below.]

I assume 1) and 2) will have their own scatter gather lists in the "request" layer. Describing that as DMA_BIDIR makes me feel a bit uneasy. It is definitely better that a binary "rw" flag. Couldn't the HBA have different inbound and outbound DMA engines associated with different PCI devices?

My concern stated a different way is that a "bidi" SCSI command using two scatter gather lists at the initiator end looks very similar to two queued SCSI commands: typically a READ queued behind a WRITE. We don't consider the latter pair (PCI_)DMA_BIDIRECTIONAL.

On rereading your comments above, are you planning to retire the DMA_BIDIRECTIONAL flag in the future?

** various SCSI transports have a mechanism for sending
some data_out with the cdb. Some transports allow the device server to control that via the "first burst size" field in the disconnect-reconnect mode page. I have been told that all known SAS implementations set that field to zero (and some want the capability removed from the standard). FCP?

***Both SAS and FCP control data_out transfers indirectly
via the XFER_RDY (t->i) frame.

Doug Gilbert

#24 lore raw
Quoted 115 lines · Douglas Gilbert
Quoted 70 lines · Boaz Harrosh

Following are 4 (large) patches for support of bidirectional block I/O in kernel. (not including SCSI-ml or iSCSI)

The submitted work is against linux-2.6-block tree as of 2007/04/15, and will only cleanly apply in succession.

The patches are based on the RFC I sent 3 months ago. They only cover the block layer at this point. I suggest they get included in Morton's tree until they reach the kernel so they can get compiled on all architectures/platforms. There is still a chance that architectures I did not compile were not fully converted. (FWIW, my search for use of struct request members failed to find them). If you find such a case, please send me the file name and I will fix it ASAP.

Patches summary:
1. [PATCH 1/4] bidi support: request dma_data_direction
- Convert REQ_RW bit flag to a dma_data_direction member like in SCSI-ml use.
- removed rq_data_dir() and added other APIs for querying request's direction.
- fix usage of rq_data_dir() and peeking at req->cmd_flags & REQ_RW to using new api.
- clean-up bad usage of DMA_BIDIRECTIONAL and bzero of none-queue requests, to use the new blk_rq_init_unqueued_req()

2. [PATCH 2/4] bidi support: fix req->cmd == INT cases
- Digging into all these old drivers, I have found traces of past life where request->cmd was the command type. This patch fixes some of these places. All drivers touched by this patch are clear indication of drivers that were not used for a while. Should we removed them from Kernel? These Are:
drivers/acorn/block/fd1772.c, drivers/acorn/block/mfmhd.c, drivers/block/nbd.c, drivers/cdrom/aztcd.c, drivers/cdrom/cm206.c drivers/cdrom/gscd.c, drivers/cdrom/mcdx.c, drivers/cdrom/optcd.c drivers/cdrom/sjcd.c, drivers/ide/legacy/hd.c, drivers/block/amiflop.c

2. [PATCH 3/4] bidi support: request_io_part
- extract io related fields in struct request into struct request_io_part in preparation to full bidi support.
- new rq_uni() API to access the sub-structure. (Please read below comment on why an API and not open code the access)
- Convert All users to new API.

3. [PATCH 4/4] bidi support: bidirectional block layer
- add one more request_io_part member for bidi support in struct request.
- add block layer API functions for mapping and accessing bidi data buffers and for ending a block request as a whole (end_that_request_block())

--------------------------------------------------------------------------------------------
Developer comments:

patch 1/4: Borrow from struct scsi_cmnd use of enum dma_data_direction. Further work (in progress) is the removal of the corresponding member from struct scsi_cmnd and converting all users to directly access rq_dma_dir(sc->req).

patch 3/4: The reasons for introducing the rq_uni(req) API rather than directly accessing req->uni are:

* WARN(!bidi_dir(req)) is life saving when developing bidi enabled paths. Once we, bidi users, start to push bidi requests down the kernel paths, we immediately get warned of paths we did not anticipate. Otherwise, they will be very hard to find, and will hurt kernel stability.

* A cleaner and saner future implementation could be in/out members rather than uni/bidi_read. This way the dma_direction member can deprecated and the uni sub- structure can be maintained using a pointer in struct req.
With this API we are free to change the implementation in the future without touching any users of the API. We can also experiment with what's best. Also, with the API it is much easier to convert uni-directional drivers for bidi (look in ll_rw_block.c in patch 4/4).

Quoted 2 lines

* Note, that internal uses inside the block layer access req->uni directly, as they will need to be changed if the implementation of req->{uni, bidi_read} changes.

Boaz,
Recently I have been looking at things from the perspective of a SAS target and thinking about bidi commands. Taking XDWRITEREAD(10) in sbc3r09.pdf (section 5.44) as an example, with DISABLE_WRITE=0, the "device server" in the target should do the following:
a) decode the cdb **
b) read from storage [lba, transfer_length]
c) fetch data_out from initiator [transfer_length] ***
d) XOR data from (b) and (c) and place result in (z)
e) write the data from (c) to storage [lba, transfer_length]
f) send (z) in data_in to initiator [transfer_length]
g) send SCSI completion status to initiator

Logically a) must occur first and g) last. The b) to f) sequence could be repeated (perhaps) by the device server subdividing the transfer_length (i.e. it may not be reasonable for the OS to assume that the data_out transfer will be complete before there is any data_in transfer). With this command (and with most other bidi commands I suspect) there is little opportunity for full duplex data movement within this command (i.e. little or no data associated with this command moving both ways "on the wire" at the same time).

Seen from sgv4 and the initiator we basically set up the resources that the target's device server uses during the execution of that command:
0) cdb [XDWRITEREAD(lba,transfer_length)]
1) data_out buffer ("write" out to device)
2) data_in buffer ("read" in from device)
3) sense buffer (in case of problems)
4) SCSI (and transport) completion status

After setting up 1), 2) and 3), the initiator pushes 0) to the target (lu) and then waits until it is told 4) is finished. The order in which 1) and 2) are used is dictated by the device server in the target. [Pushing 0) and 1) can be partially combined in the ** case, see below.]

Quoted 5 lines

I assume 1) and 2) will have their own scatter gather lists in the "request" layer. Describing that as DMA_BIDIR makes me feel a bit uneasy. It is definitely better that a binary "rw" flag. Couldn't the HBA have different inbound and outbound DMA engines associated with different PCI devices?

Yes there are two mapped, ready to use, scatter gather lists before the send of 0. We assume no order and support full duplex. Actually in my OSD tests over iSCSI, because of how iSCSI is built with it's threads, there where times the 2 buffers where actually written/read at the same time.

Quoted 7 lines

My concern stated a different way is that a "bidi" SCSI command using two scatter gather lists at the initiator end looks very similar to two queued SCSI commands: typically a READ queued behind a WRITE. We don't consider the latter pair (PCI_)DMA_BIDIRECTIONAL.

Let me start with saying that you are absolutely right.

The use of the enum dma_data_direction was borrowed from struct scsi_cmnd and its users. There was no reason to invent yet another enum, another inconsistency, and another translation layer. Part of my patches which you did not yet see, is a cleanup to the SCSI-ml and struct scsi_cmnd, removing the sc_data_direction member and directly use the struct request API.

The use of PCI_DMA_XXX #defines and the DMA_XXX enum is intermixed wrongfully. The current pattern is to use PCI_DMA_XXX as an int type when used with DMA/PCI data transfer engines, in contrast, the use of enum dma_data_direction is supposed to be confined to the use of struct scsi_cmnd, denoting the command direction/type. The two are wrongly intermixed in places, and should be fixed.

Sigh ...

Quoted 4 lines

On rereading your comments above, are you planning to retire the DMA_BIDIRECTIONAL flag in the future?

Yes, absolutely. Once things stabilize I'll send an RFC to see how it comes out.

Quoted 13 lines

** various SCSI transports have a mechanism for sending
some data_out with the cdb. Some transports allow the device server to control that via the "first burst size" field in the disconnect-reconnect mode page. I have been told that all known SAS implementations set that field to zero (and some want the capability removed from the standard). FCP?

***Both SAS and FCP control data_out transfers indirectly
via the XFER_RDY (t->i) frame.

Doug Gilbert