linux-kernel - Re: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.

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]

Message-ID: <1409324497.1223.383.camel@localhost.localdomain>
Date:	Fri, 29 Aug 2014 11:01:37 -0400
From:	Ewan Milne <emilne@...hat.com>
To:	Mike Christie <michaelc@...wisc.edu>
Cc:	Hannes Reinecke <hare@...e.de>,
	Christoph Hellwig <hch@...radead.org>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	linux-kernel@...r.kernel.org, devel@...uxdriverproject.org,
	ohering@...e.com, jbottomley@...allels.com,
	linux-scsi@...r.kernel.org,
	"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs
 that may have been removed.

On Thu, 2014-08-28 at 21:42 -0500, Mike Christie wrote:
> On 08/27/2014 09:31 AM, Hannes Reinecke wrote:
> > On 08/19/2014 07:54 PM, Christoph Hellwig wrote:
> >> On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote:
> >>> The host asks the guest to scan when a LUN is removed or added.
> >>> The only way a guest can identify the removed LUN is when an I/O is
> >>> attempted on a removed LUN - the SRB status code indicates that the LUN
> >>> is invalid. We currently handle this SRB status and remove the device.
> >>>
> >>> Rather than waiting for an I/O to remove the device, force the
> >>> discovery of
> >>> LUNs that may have been removed prior to discovering LUNs that may have
> >>> been added.
> >>
> >> This looks pretty reasonable to me, but I wonder if we should move this
> >> up to common code so that it happens for any host rescan triggered by
> >> sysfs or other drivers as well.
> >>
> > Not without proper testing.
> > Currently we cannot rescan existing devices; the inquiry string is
> > nailed to the sdev structure. The only way to really refresh the
> > information is to delete it and rescan it again.
> 
> How are distros handling 0x6/0x3f/0x0e (report luns changed) when it
> gets passed to userspace? Is everyone kicking off a new full (add and
> delete) scan to handle this or logging it? Is the driver returning this
> when the LUNs change?

Currently the udev rules we have to handle these events are installed
with a separate package, and only the REPORTED LUNS DATA HAS CHANGED
does anything, the others are commented out.  It turns out that e.g.
multipath stops using a path if it notices that the capacity has changed
and we need to do some more work there, it is under discussion.

We do not delete LUNs that disappear from the REPORT LUNS inventory,
although someone could write their own udev rule to do that if desired.

Beware the case where a LUN is remapped to a different LUN number, or
if LUN's WWID is used for a device with different data (e.g. a LUN
deleted and re-added and the WWID is the same although I don't know
if this actually happens).

Consider that the UA just provides notification to userspace of a
change -- lack of notification does not prevent someone from deciding
to rescan for new LUNs via sysfs any time they feel like it.  So
you can't just change the storage configuration and hope that no-one
notices until you are done making changes.

-Ewan

> 
> Also is the driver getting a 0x5/0x25/0 (invalid LUN) when the LUN does
> not exist, or is it just getting that SRB_STATUS_INVALID_LUN error code?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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