[an error occurred while processing this directive]

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

[an error occurred while processing this directive]

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

Message-Id: <1379077109-29606-1-git-send-email-apw@canonical.com>
Date:	Fri, 13 Sep 2013 13:58:25 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	"James E.J. Bottomley" <JBottomley@...allels.com>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>
Cc:	Andy Whitcroft <apw@...onical.com>,
	Ben Howard <ben.howard@...onical.com>,
	linux-scsi@...r.kernel.org, devel@...uxdriverproject.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] Hyper-V TRIM support

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?

-apw

Andy Whitcroft (4):
  scsi: add scsi device flag to request VPD pages be used at SPC-2
  scsi: add scsi device flag to request READ CAPACITY (16) be preferred
  scsi: hyper-v storage -- mark as VPD capable at SPC-2
  scsi: hyper-v storage -- mark as preferring READ CAPACITY (16) at
    SPC-2

 drivers/scsi/sd.c          | 8 +++++++-
 drivers/scsi/storvsc_drv.c | 2 ++
 include/scsi/scsi_device.h | 2 ++
 3 files changed, 11 insertions(+), 1 deletion(-)

-- 
1.8.1.2

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