linux-kernel - Re: [PATCH 0/4] Hyper-V TRIM support

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:	Fri, 13 Sep 2013 07:57:58 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andy Whitcroft <apw@...onical.com>
Cc:	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Ben Howard <ben.howard@...onical.com>,
	linux-scsi@...r.kernel.org, devel@...uxdriverproject.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Hyper-V TRIM support

On Fri, 2013-09-13 at 13:58 +0100, Andy Whitcroft wrote:
> tl;dr -- enable TRIM support for Hyper-V emulated disks.
> 
> The Hyper-V hypervisor can support TRIM for its devices, advertising this
> via the appropriate VPD pages.  However the emulated disks only claim
> to be SPC-2 devices.  According to the specs VPD pages (in general) did
> exist at SPC-2 but the specific pages we interogate for the TRIM support
> did not until SPC-3 therefore the kernel avoids reading the relevant pages
> for SPC-2 devices and prevents TRIM from being offered for these devices.
> Additionally at SPC-2 we prefer ReadCapacity10 over ReadCapacity16 and
> unless we use RC16 we will not identify the device as TRIM capable also
> preventing TRIM being offered.
> 
> As the VPD page zero does list which pages are valid for each device, it
> could be argued that we could simply attempt to use these pages for all
> devices which claim to be SPC-2 and above.  While this seems valid the
> code documents a number of devices which take badly to having even VPD
> page 0 interogated even when supposedly supported.  Therefore it seems
> appropriate to add a scsi device flag to allow a device to request SPC-3
> VPD pages be used when only at SPC-2.
> 
> Similarly for the ReadCapacity selection it seems dangerous to invert
> the order for all SPC-2 devices.  So it seems appropriate to add a scsi
> device flag to request we try RC16 before RC10 (mirroring the existing
> flag for the opposite).
> 
> The following four patches add the two scsi device flags and select those
> flags for the Hyper-V emulated disks.
> 
> Patches against v3.11.
> 
> Comments?

This is an awful lot of contortions (which don't seem to have any other
users on the horizon) to support a device that's not standards
compliant.  What about this, it's simple, it does the right thing and
it's contained in the driver of the problem device.

James

---

diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 83ec1aa..bd86a4b 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1438,6 +1438,12 @@ static int storvsc_device_configure(struct scsi_device *sdevice)
 
 	sdevice->no_write_same = 1;
 
+	/*
+	 * hyper-v is stupid and lies about its capabilities
+	 * If we pretend to be SPC-3, we send RC16 which activates trim
+	 */
+	sdevice->scsi_level = SCSI_SPC_3;
+
 	return 0;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/