Jens Axboe wrote:
This looks like the real bug.
---
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 4afef5c..0978887 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1215,12 +1215,12 @@ static int scsi_prep_fn(struct request_q
} else {
memcpy(cmd->cmnd, req->cmd, sizeof(cmd->cmnd));
cmd->cmd_len = req->cmd_len;
- if (rq_data_dir(req) == WRITE)
+ 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 if (req->data_len)
- cmd->sc_data_direction = DMA_FROM_DEVICE;
else
- cmd->sc_data_direction = DMA_NONE;
+ cmd->sc_data_direction = DMA_FROM_DEVICE;
cmd->transfersize = req->data_len;
cmd->allowed = 3;
And then there are also sd_init_command(), sr_init_command(),
st_init_command() in s[drt].c. sr_init_command() looks OK to me, the
other two feature the same flaw like scsi_prep_fn().
Or is there any reason why they should set DMA_TO_DEVICE while
rq->data_len == 0?
Furthermore, is there any other code path which may set
cmd->sc_data_direction, aside from s[drt]_init_command() and
scsi_prep_fn()? I was just browsing the code to find out myself but am
not 100% sure.
--
Stefan Richter
-=====-=-=-= ==-- -=--=
http://arcgraph.de/sr/
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
