scsi: hosts: check result of scsi_host_set_state() in scsi_add_host_with_dma()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


SCSI core uses scsi_host_set_state() to control the host's state machine;
this function returns 0 on success and -EINVAL on failure to change host's
state. The only place where the result of scsi_host_set_state() is ignored
is in scsi_add_host_with_dma() -- that blithely continues initializing the
SCSI host even if the host's state couldn't be set to SHOST_RUNNING...
I guess the logic behind this is that scsi_add_host_with_dma() call is
always preceded by scsi_host_alloc() call which leaves the host's state
machine in the SHOST_CREATED state which is a valid previous state for
SHOST_RUNNING. I think we'd better check result of scsi_host_set_state()
always -- better safe than sorry!

Found by Linux Verification Center ( with the Svace static
analysis tool.

Signed-off-by: Sergey Shtylyov <s.shtylyov@xxxxxx>

The patch is against the 'for-next' branch of Martin Petersen's 'scsi.git' repo.

 drivers/scsi/hosts.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: scsi/drivers/scsi/hosts.c
--- scsi.orig/drivers/scsi/hosts.c
+++ scsi/drivers/scsi/hosts.c
@@ -272,7 +272,10 @@ int scsi_add_host_with_dma(struct Scsi_H
 	if (error)
 		goto out_disable_runtime_pm;
-	scsi_host_set_state(shost, SHOST_RUNNING);
+	error = scsi_host_set_state(shost, SHOST_RUNNING);
+	if (error)
+		goto out_disable_runtime_pm;

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux