[PATCH] scsi: mpt2sas: mpt2sas_base.c: Cleaning up wrong return value
A variable to manage the error code is not returned. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/scsi/mpt2sas/mpt2sas_base.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c b/drivers/scsi/mpt2sas/mpt2sas_base.c index bde63f7..ed10b74f 100644 --- a/drivers/scsi/mpt2sas/mpt2sas_base.c +++ b/drivers/scsi/mpt2sas/mpt2sas_base.c @@ -3546,7 +3546,7 @@ _base_send_ioc_init(struct MPT2SAS_ADAPTER *ioc, int sleep_flag) r = -EIO; } - return 0; + return r; } /** -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi: mpt3sas: mpt3sas_base.c: Cleaning up wrong return value
A variable to manage the error code is not returned. This was partly found using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist --- drivers/scsi/mpt3sas/mpt3sas_base.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c b/drivers/scsi/mpt3sas/mpt3sas_base.c index 0cf4f70..1140b0a 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -3715,7 +3715,7 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc, int sleep_flag) r = -EIO; } - return 0; + return r; } /** -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] target fixes for v3.15
Hi Linus, Here are the remaining fixes for v3.15. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master This series includes: - iser-target fix for ImmediateData exception reference count bug (Sagi + nab) - iscsi-target fix for MC/S login + potential iser-target MRDSL buffer overrun (Santosh + Roland) - iser-target fix for v3.15-rc multi network portal shutdown regression (nab) - target fix for allowing READ_CAPCITY during ALUA Standby access state (Chris + nab) - target fix for NULL pointer dereference of alua_access_state for un-configured devices (Chris + nab) Thank you, --nab Nicholas Bellinger (4): iser-target: Add missing target_put_sess_cmd for ImmedateData failure iser-target: Fix multi network portal shutdown regression target: Allow READ_CAPACITY opcode in ALUA Standby access state target: Fix alua_access_state attribute OOPs for un-configured devices Roland Dreier (1): iscsi-target: Fix wrong buffer / buffer overrun in iscsi_change_param_value() drivers/infiniband/ulp/isert/ib_isert.c |2 + drivers/target/iscsi/iscsi_target.c |1 + drivers/target/iscsi/iscsi_target_login.c | 70 + drivers/target/iscsi/iscsi_target_tpg.c |3 +- drivers/target/target_core_alua.c |9 drivers/target/target_core_configfs.c |5 +++ 6 files changed, 50 insertions(+), 40 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SCSI eats error from flush failure during hot plug
On Thu, 2014-06-05 at 16:52 -0700, Steven Haber wrote: > Hello, > > I am testing ATA device durability during hot unplug. I have a power > fault test suite that has turned up issues with the fsync->SCSI->ATA > codepath. If a device is unplugged while an fsync is in progress, ATA > returns a flush error to the SCSI driver but scsi_io_completion() > seems to disregard it. fsync() returns no error, which should mean > that the write was durably flushed to disk. I expect fsync() to return > EIO or something similar when the flush isn't acked by the device. > > When the failure occurs, the SCSI sense key is set to ABORTED_COMMAND. > However, scsi_end_command() is called without any of the sense context > and scsi_io_completion() returns early without checking sense at all. > > This commit may be related: > d6b0c53723753fc0cfda63f56735b225c43e1e9a > (http://git.opencores.org/?a=commitdiff&p=linux&h=d6b0c53723753fc0cfda63f56735b225c43e1e9a) > > The following patch fixes the issue, but it's a hack. I only have a > vague understanding of Linux drivers, so I'm looking for advice on how > to make this fix better and get it upstream. OK, so for some reason this is a zero size REQ_TYPE_FS command, which the logic actually assumes we cannot have. I suspect REQ_TYPE_FLUSH subtly broke this logic because it's coming back to us as REQ_TYPE_FS even though it's been set up (in SCSI) as REQ_TYPE_BLOCK_PC. On this theory, we'd eat the return codes of all no data transfer commands that fail. I think the generic fix is to make sure that all commands initiallised as REQ_TYPE_BLOCK_PC actually have the ->cmd_type set to that. There may be some knock on side effects because it doesn't look like the block flush code expects us to change the request->cmd_type. Cc'd Jens for opinions on this. Can you try this out and see if it fixes the problem? If it doesn't, we're going to have to get into debugging exactly what this zero length request is. Thanks, James --- diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 9db097a..78229ec7 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1171,6 +1171,11 @@ int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req) cmd->transfersize = blk_rq_bytes(req); cmd->allowed = req->retries; + /* +* Thanks to flush and other PC prepared commands, we may +* not be a REQ_TYPE_BLOCK_PC; make sure we are +*/ + req->cmd_type = REQ_TYPE_BLOCK_PC; return BLKPREP_OK; } EXPORT_SYMBOL(scsi_setup_blk_pc_cmnd); -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
