| Message ID | 20180806045115.7725-6-dgilbert@interlog.com (mailing list archive) |
|---|---|
| State | Deferred |
| Headers | show |
| Series | sd: init_command() and sd_done() speed-ups | expand |
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 05014054e357..9cf88392e994 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2007,6 +2007,7 @@ static int sd_done(struct scsi_cmnd *SCpnt) } } else { switch (req_op(req)) { + case REQ_OP_FLUSH: case REQ_OP_DISCARD: case REQ_OP_WRITE_ZEROES: case REQ_OP_WRITE_SAME:
REQ_OP_FLUSH appears in the submission path processing but not in the response path processing. Hence it takes the "default" case which seems to be designed for REQ_OP_READ and REQ_OP_WRITE. So add a REQ_OP_FLUSH case to the response path. Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> --- Is it correct to treat REQ_OP_FLUSH like the other OPs that may send but never return data (as in a READ's data-in)? Should this be fixed separately in the mainline? drivers/scsi/sd.c | 1 + 1 file changed, 1 insertion(+)