linux-kernel - Re: [PATCH 2/3] [SCSI] storvsc: Add Hyper-V logical block provisioning tests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Jul 2014 14:09:11 +0000
From:	James Bottomley <jbottomley@...allels.com>
To:	"sitsofe@...il.com" <sitsofe@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"hch@...radead.org" <hch@...radead.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"apw@...onical.com" <apw@...onical.com>,
	"kys@...rosoft.com" <kys@...rosoft.com>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"ohering@...e.com" <ohering@...e.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jasowang@...hat.com" <jasowang@...hat.com>
Subject: Re: [PATCH 2/3] [SCSI] storvsc: Add Hyper-V logical block
 provisioning tests

On Thu, 2014-07-24 at 08:56 +0100, Sitsofe Wheeler wrote:
> Microsoft Hyper-V targets currently only claim SPC-2 compliance / no
> compliance indicated even though they implement post SPC-2 features
> which means those features are not tested for. Add a blacklist flag to
> Hyper-V devices that forces said testing.

This description is misleading: you don't force the test now, you force
the driver to send unmap commands down to the device.

> See https://lkml.org/lkml/2014/7/21/627 for the previous version of this
> patch and https://lkml.org/lkml/2014/7/23/615 for example devices.
> 
> Original-patch-by: K. Y. Srinivasan <kys@...rosoft.com>
> Signed-off-by: Sitsofe Wheeler <sitsofe@...oo.com>
> ---
>  drivers/scsi/storvsc_drv.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5ad2810..88b7173 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -326,8 +326,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)");
>   */
>  static int storvsc_timeout = 180;
>  
> -static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
> -
>  #define STORVSC_MAX_IO_REQUESTS				200
>  
>  static void storvsc_on_channel_callback(void *context);
> @@ -1444,12 +1442,10 @@ static int storvsc_device_configure(struct scsi_device *sdevice)
>  	sdevice->no_write_same = 1;
>  
>  	/*
> -	 * Add blist flags to permit the reading of the VPD pages even when
> -	 * the target may claim SPC-2 compliance. MSFT targets currently
> -	 * claim SPC-2 compliance while they implement post SPC-2 features.
> -	 * With this patch we can correctly handle WRITE_SAME_16 issues.
> +	 * Forcefully enable logical block provisioning testing.
>  	 */
> -	sdevice->sdev_bflags |= msft_blist_flags;
> +	sdevice->sdev_bflags |= BLIST_TRY_LBP;
> +	sdevice->try_lbp = 1;

Really no way to this one.  You're forcing unmap support on every
hyper-v device; including spinning rust pass through ones which won't
support it.  The hyper-v storage interface has proven to be somewhat
fragile, so it may explode when the device tries to send illegal command
sense back.

If you have a specific IDENTITY string for a faulty SSD that fails to
report unmap support correctly, then we could quirk for that, but not
everything attached to the hyper-v driver.

James