KY Srinivasan <kys@xxxxxxxxxxxxx> writes: >> -----Original Message----- >> From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] >> Sent: Thursday, June 25, 2015 9:12 AM >> To: linux-scsi@xxxxxxxxxxxxxxx >> Cc: Long Li; KY Srinivasan; Haiyang Zhang; James E.J. Bottomley; >> devel@xxxxxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Radim Krčmář >> Subject: [PATCH] scsi: storvsc: be more picky about scmnd- >> >sc_data_direction >> >> Under the 'default' case in scmnd->sc_data_direction we have 3 options: >> - DMA_NONE which we handle correctly. >> - DMA_BIDIRECTIONAL which is never supposed to be set by SCSI stack. >> - Garbage value. >> >> Do WARN() and return -EINVAL in the last two cases. virtio_scsi does >> BUG_ON() here but it looks like an overkill. >> >> Reported-by: Radim Krčmář <rkrcmar@xxxxxxxxxx> >> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> > Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> Sorry for the ping but it seems the fix never made it to scsi tree... >> --- >> drivers/scsi/storvsc_drv.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c >> index 3c6584f..61f4855 100644 >> --- a/drivers/scsi/storvsc_drv.c >> +++ b/drivers/scsi/storvsc_drv.c >> @@ -1598,10 +1598,18 @@ static int storvsc_queuecommand(struct >> Scsi_Host *host, struct scsi_cmnd *scmnd) >> vm_srb->data_in = READ_TYPE; >> vm_srb->win8_extension.srb_flags |= >> SRB_FLAGS_DATA_IN; >> break; >> - default: >> + case DMA_NONE: >> vm_srb->data_in = UNKNOWN_TYPE; >> vm_srb->win8_extension.srb_flags |= >> SRB_FLAGS_NO_DATA_TRANSFER; >> break; >> + default: >> + /* >> + * This is DMA_BIDIRECTIONAL or something else we are >> never >> + * supposed to see here. >> + */ >> + WARN(1, "Unexpected data direction: %d\n", >> + scmnd->sc_data_direction); >> + return -EINVAL; >> } >> >> >> -- >> 2.4.3 -- Vitaly -- To unsubscribe from this list: 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
