public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Another fix for suspend i/o - validate dev state before transition
@ 2004-11-17 18:39 James.Smart
  2004-12-11  4:48 ` James Bottomley
  0 siblings, 1 reply; 3+ messages in thread
From: James.Smart @ 2004-11-17 18:39 UTC (permalink / raw)
  To: linux-scsi

The block/unblock patch reports stack dumps and illegal transitions when the driver continues to call block or unblock after the device has failed (moved into offline state due to i/o error, etc). The LLDD/transport is unaware of the sdev transition, so it doesn't know better.

This patch has the internal device block/unblock routines validate the state transition before invoking it.

Hopefully this is it for this darn feature...

-- James S




--- scsi_lib.c.2.6.10-rc2	2004-11-16 09:03:58.000000000 -0500
+++ scsi_lib.c.NEW	2004-11-17 13:23:22.340667480 -0500
@@ -1813,6 +1813,12 @@
  *	state, all commands are deferred until the scsi lld reenables
  *	the device with scsi_device_unblock or device_block_tmo fires.
  *	This routine assumes the host_lock is held on entry.
+ *
+ *      As the LLDD/Transport that is calling this function doesn't
+ *	actually know what the device state is, the function may be
+ *	called at an inappropriate time. Therefore, before requesting
+ *	the state change, the function validates that the transition is
+ *	valid.
  **/
 int
 scsi_internal_device_block(struct scsi_device *sdev)
@@ -1821,6 +1827,10 @@
 	unsigned long flags;
 	int err = 0;
 
+	if ((sdev->sdev_state != SDEV_CREATED) &&
+	    (sdev->sdev_state != SDEV_RUNNING))
+		return 0;
+
 	err = scsi_device_set_state(sdev, SDEV_BLOCK);
 	if (err)
 		return err;
@@ -1853,6 +1863,12 @@
  *	(which must be a legal transition) allowing the midlayer to
  *	goose the queue for this device.  This routine assumes the 
  *	host_lock is held upon entry.
+ *
+ *      As the LLDD/Transport that is calling this function doesn't
+ *	actually know what the device state is, the function may be
+ *	called at an inappropriate time. Therefore, before requesting
+ *	the state change, the function validates that the transition is
+ *	valid.
  **/
 int
 scsi_internal_device_unblock(struct scsi_device *sdev)
@@ -1861,6 +1877,9 @@
 	int err;
 	unsigned long flags;
 	
+	if (sdev->sdev_state != SDEV_BLOCK)
+		return 0;
+	
 	/* 
 	 * Try to transition the scsi device to SDEV_RUNNING
 	 * and goose the device queue if successful.  

^ permalink raw reply	[flat|nested] 3+ messages in thread
* RE: [PATCH] Another fix for suspend i/o - validate dev state before transition
@ 2004-11-30 21:17 James.Smart
  0 siblings, 0 replies; 3+ messages in thread
From: James.Smart @ 2004-11-30 21:17 UTC (permalink / raw)
  To: James.Smart, linux-scsi

James,

I have yet to see this hit scsi-misc-2.6...  hope it didn't get dropped.

-- james

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org]On Behalf Of Smart, James
> Sent: Wednesday, November 17, 2004 1:40 PM
> To: linux-scsi@vger.kernel.org
> Subject: [PATCH] Another fix for suspend i/o - validate dev 
> state before
> transition
> 
> 
> The block/unblock patch reports stack dumps and illegal 
> transitions when the driver continues to call block or 
> unblock after the device has failed (moved into offline state 
> due to i/o error, etc). The LLDD/transport is unaware of the 
> sdev transition, so it doesn't know better.
> 
> This patch has the internal device block/unblock routines 
> validate the state transition before invoking it.
> 
> Hopefully this is it for this darn feature...
> 
> -- James S
> 
> 
> 
> 
> --- scsi_lib.c.2.6.10-rc2	2004-11-16 09:03:58.000000000 -0500
> +++ scsi_lib.c.NEW	2004-11-17 13:23:22.340667480 -0500
> @@ -1813,6 +1813,12 @@
>   *	state, all commands are deferred until the scsi lld reenables
>   *	the device with scsi_device_unblock or device_block_tmo fires.
>   *	This routine assumes the host_lock is held on entry.
> + *
> + *      As the LLDD/Transport that is calling this function doesn't
> + *	actually know what the device state is, the function may be
> + *	called at an inappropriate time. Therefore, before requesting
> + *	the state change, the function validates that the transition is
> + *	valid.
>   **/
>  int
>  scsi_internal_device_block(struct scsi_device *sdev)
> @@ -1821,6 +1827,10 @@
>  	unsigned long flags;
>  	int err = 0;
>  
> +	if ((sdev->sdev_state != SDEV_CREATED) &&
> +	    (sdev->sdev_state != SDEV_RUNNING))
> +		return 0;
> +
>  	err = scsi_device_set_state(sdev, SDEV_BLOCK);
>  	if (err)
>  		return err;
> @@ -1853,6 +1863,12 @@
>   *	(which must be a legal transition) allowing the midlayer to
>   *	goose the queue for this device.  This routine assumes the 
>   *	host_lock is held upon entry.
> + *
> + *      As the LLDD/Transport that is calling this function doesn't
> + *	actually know what the device state is, the function may be
> + *	called at an inappropriate time. Therefore, before requesting
> + *	the state change, the function validates that the transition is
> + *	valid.
>   **/
>  int
>  scsi_internal_device_unblock(struct scsi_device *sdev)
> @@ -1861,6 +1877,9 @@
>  	int err;
>  	unsigned long flags;
>  	
> +	if (sdev->sdev_state != SDEV_BLOCK)
> +		return 0;
> +	
>  	/* 
>  	 * Try to transition the scsi device to SDEV_RUNNING
>  	 * and goose the device queue if successful.  
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-12-11  4:48 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-17 18:39 [PATCH] Another fix for suspend i/o - validate dev state before transition James.Smart
2004-12-11  4:48 ` James Bottomley
  -- strict thread matches above, loose matches on Subject: below --
2004-11-30 21:17 James.Smart

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