public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* Concurrent SG_SCSI_RESET ioctls
@ 2014-10-10 23:32 Elliott, Robert (Server Storage)
  2014-10-11 11:05 ` Christoph Hellwig
  2014-10-11 16:11 ` Christoph Hellwig
  0 siblings, 2 replies; 13+ messages in thread
From: Elliott, Robert (Server Storage) @ 2014-10-10 23:32 UTC (permalink / raw)
  To: James Bottomley (jbottomley@parallels.com), Christoph Hellwig,
	dgilbert@interlog.com, linux-scsi@vger.kernel.org
  Cc: Don Brace (PMC), Scales, Webb

The sg3_utils command
	sg_reset --device /dev/sda

invokes an ioctl with SG_SCSI_RESET, an argument of
SG_SCSI_RESET_DEVICE, on a device opened with O_NDELAY.

The call chain is like this:

sd_ioctl					[sd.c]
	scsi_nonblockable_ioctl		[scsi_ioctl.c]
		if (ndelay) {			[this is true]
			if (scsi_host_in_recovery(sdev->host))
				return -ENODEV;
			}
		scsi_reset_provider		[scsi_error.c]
			shost->tmf_in_progress = 1;
			scsi_try_bus_device_reset [scsi_error.c]
				hostt->eh_device_reset_handler [LLD]
			shost->tmf_in_progress = 1;
	if that returns 0, return; otherwise try:
	scsi_cmd_blk_ioctl
	scsi_ioctl
		sdev->host->hostt->ioctl	[LLD]

where scsi_host_in_recovery is:

static inline int scsi_host_in_recovery(struct Scsi_Host *shost)
{
        return shost->shost_state == SHOST_RECOVERY ||
                shost->shost_state == SHOST_CANCEL_RECOVERY ||
                shost->shost_state == SHOST_DEL_RECOVERY ||
                shost->tmf_in_progress;
}

Problem
=======
If you run sg_reset --device concurrently to multiple
devices on the same host, then some of them will run
into tmf_in_progress and have scsi_nonblockable_ioctl
return -ENODEV.  This causes sd_ioctl to send the ioctl
request to the LLD's ioctl function, where it gets
rejected as unsupported with -ENOTTY.  sg_reset ends
up displaying:
	sg_reset: SG_SCSI_RESET failed: Inappropriate ioctl for device

Any suggestions for how to fix this?  

Is the check of scsi_host_in_recovery, which includes
tmf_in_progress, too strong?  Most LLDs are not parallel
SCSI where you can just have one TMF on the bus at a
time anymore.

Is returning -ENODEV if the host is in recovery the
wrong code?  There might be a device there...it's
just that access is temporarily blocked.

Should sd_ioctl not proceed to scsi_ioctl in so many
cases? Perhaps it should:
  * proceed if it gets back -EINVAL (and maybe -ENOTTY)
    indicating the ioctl specified was bad
  * return if it gets back any other error (e.g., -ENODEV,
    -EACCESS, or -EIO) 
That would at least result in a more meaningful error.

Also, should scsi_nonblockable_ioctl return -ENOTTY rather
than -ENODEV if cmd is unsupported?  There's not really
a no-device problem.

---
Rob Elliott    HP Server Storage


^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-10-24 16:30 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-10 23:32 Concurrent SG_SCSI_RESET ioctls Elliott, Robert (Server Storage)
2014-10-11 11:05 ` Christoph Hellwig
2014-10-11 16:11 ` Christoph Hellwig
2014-10-11 22:06   ` Elliott, Robert (Server Storage)
2014-10-14 11:13     ` Christoph Hellwig
2014-10-14 16:42       ` Douglas Gilbert
2014-10-15 13:25         ` Christoph Hellwig
2014-10-15 14:34           ` Elliott, Robert (Server Storage)
2014-10-24 14:51         ` Christoph Hellwig
2014-10-24 16:29           ` Douglas Gilbert
2014-10-11 23:04   ` Elliott, Robert (Server Storage)
2014-10-13  9:15   ` Bart Van Assche
2014-10-13 10:23     ` Christoph Hellwig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox