Re: [PATCH 3/3] sd: error handling synchronizing caches

[James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2012-08-01 at 16:44 +0200, Oliver Neukum wrote:
> sd_sync_cache() can fail in several manners.
> As the error return is passed to the generic layer,
> it must be correctly processed.
> 
> Failures due to unplugged devices or removed media
> should be ignored. In the other cases retryable and
> fatal errors must be differentiated.
> 
> This fixes a problem with unplugging eSATA devices
> before suspending the system.
> 
> Signed-off-by: Oliver Neukum <oneukum@xxxxxxx>
> ---
>  drivers/scsi/sd.c |   24 ++++++++++++++++++++++++
>  1 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index a344220..49b0c52 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1278,8 +1278,32 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
>  
>  	if (res) {
>  		sd_print_result(sdkp, res);
> +
>  		if (driver_byte(res) & DRIVER_SENSE)
>  			sd_print_sense_hdr(sdkp, &sshdr);
> +			/* we need to evaluate the error return  */
> +			if ((scsi_sense_valid(&sshdr) &&

The indentation is completely wrong here ... it's implying that the
first if should have an opening brace.

> +				/* 0x3a is medium not present */
> +				sshdr.asc == 0x3a))
> +					/* this is no error here */
> +					return 0;
> +
> +			switch (host_byte(res)) {
> +			/* ignore errors due to racing a disconnection */
> +			case DID_BAD_TARGET:
> +			case DID_NO_CONNECT:
> +				return 0;
> +			/* signal the upper layer it might try again */
> +			case DID_BUS_BUSY:
> +			case DID_IMM_RETRY:
> +			case DID_REQUEUE:
> +			case DID_SOFT_ERROR:
> +				return -EBUSY;

Shouldn't you return -EBUSY for at least QUEUE_FULL and  BUSY as well?

James


> +			default:
> +				return -EIO;
> +		}
> +	} else {
> +		return 0;
>  	}
>  
>  	if (res)


--
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