linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
	James Bottomley <jbottomley@parallels.com>
Subject: Re: Kernel crash with unsupported DIF protection type
Date: Fri, 21 Sep 2012 08:03:55 +0200	[thread overview]
Message-ID: <505C034B.305@suse.de> (raw)
In-Reply-To: <yq14nmslbck.fsf@sermon.lab.mkp.net>

On 09/20/2012 09:53 PM, Martin K. Petersen wrote:
>>>>>> "Hannes" == Hannes Reinecke <hare@suse.de> writes:
> 
> Hannes> I recently got my hands on some weird drives, insisting on
> Hannes> having been formatted with protection type 7:
> 
> Lovely :|
> 
Hehe. Probably _really_ future drives :-)

> 
> Hannes> I've attached a tentative patch, which allows the system to
> Hannes> boot.  However, I'm not completely happy with that, as the
> Hannes> capacity is _still_ updated after revalidation:
> 
> How about this?
> 
> 
> sd: Ensure we correctly disable devices with unknown protection type
> 
> We set the capacity to zero when we discovered a device formatted with
> an unknown DIF protection type. However, the read_capacity code would
> override the capacity and cause the device to be enabled regardless.
> 
> Make sd_read_protection_type() return an error if the protection type is
> unknown. Also prevent duplicate printk lines when the device is being
> revalidated.
> 
> Reported-by: Hannes Reinecke <hare@suse.de>
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 1cf2d5d..1c54564 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1820,34 +1820,42 @@ sd_spinup_disk(struct scsi_disk *sdkp)
>  /*
>   * Determine whether disk supports Data Integrity Field.
>   */
> -static void sd_read_protection_type(struct scsi_disk *sdkp, unsigned char *buffer)
> +static int sd_read_protection_type(struct scsi_disk *sdkp, unsigned char *buffer)
>  {
>  	struct scsi_device *sdp = sdkp->device;
>  	u8 type;
> +	int ret = 0;
>  
>  	if (scsi_device_protection(sdp) == 0 || (buffer[12] & 1) == 0)
> -		return;
> +		return ret;
>  
>  	type = ((buffer[12] >> 1) & 7) + 1; /* P_TYPE 0 = Type 1 */
>  
> -	if (type == sdkp->protection_type || !sdkp->first_scan)
> -		return;
> +	if (type > SD_DIF_TYPE3_PROTECTION)
> +		ret = -ENODEV;
> +	else if (scsi_host_dif_capable(sdp->host, type))
> +		ret = 1;
> +
> +	if (sdkp->first_scan || type != sdkp->protection_type)
> +		switch (ret) {
> +		case -ENODEV:
> +			sd_printk(KERN_ERR, sdkp, "formatted with unsupported" \
> +				  " protection type %u. Disabling disk!\n",
> +				  type);
> +			break;
> +		case 1:
> +			sd_printk(KERN_NOTICE, sdkp,
> +				  "Enabling DIF Type %u protection\n", type);
> +			break;
> +		case 0:
> +			sd_printk(KERN_NOTICE, sdkp,
> +				  "Disabling DIF Type %u protection\n", type);
> +			break;
> +		}
>  
>  	sdkp->protection_type = type;
>  
> -	if (type > SD_DIF_TYPE3_PROTECTION) {
> -		sd_printk(KERN_ERR, sdkp, "formatted with unsupported "	\
> -			  "protection type %u. Disabling disk!\n", type);
> -		sdkp->capacity = 0;
> -		return;
> -	}
> -
> -	if (scsi_host_dif_capable(sdp->host, type))
> -		sd_printk(KERN_NOTICE, sdkp,
> -			  "Enabling DIF Type %u protection\n", type);
> -	else
> -		sd_printk(KERN_NOTICE, sdkp,
> -			  "Disabling DIF Type %u protection\n", type);
> +	return ret;
>  }
>  
>  static void read_capacity_error(struct scsi_disk *sdkp, struct scsi_device *sdp,
> @@ -1943,7 +1951,10 @@ static int read_capacity_16(struct scsi_disk *sdkp, struct scsi_device *sdp,
>  	sector_size = get_unaligned_be32(&buffer[8]);
>  	lba = get_unaligned_be64(&buffer[0]);
>  
> -	sd_read_protection_type(sdkp, buffer);
> +	if (sd_read_protection_type(sdkp, buffer) < 0) {
> +		sdkp->capacity = 0;
> +		return -ENODEV;
> +	}
>  
>  	if ((sizeof(sdkp->capacity) == 4) && (lba >= 0xffffffffULL)) {
>  		sd_printk(KERN_ERR, sdkp, "Too big for this kernel. Use a "
> 
Yup. That's what I had in mind.

Acked-by: Hannes Reinecke <hare@suse.de>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)


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

  reply	other threads:[~2012-09-21  6:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18  9:04 Kernel crash with unsupported DIF protection type Hannes Reinecke
2012-09-18  9:30 ` Douglas Gilbert
2012-09-18  9:35   ` Hannes Reinecke
2012-09-18 10:20     ` Douglas Gilbert
2012-09-20 19:53 ` Martin K. Petersen
2012-09-21  6:03   ` Hannes Reinecke [this message]
2012-09-21 14:16   ` Hannes Reinecke
2012-09-21 16:05     ` Martin K. Petersen
2012-09-21 16:44       ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=505C034B.305@suse.de \
    --to=hare@suse.de \
    --cc=jbottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).