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: <53FDEBB9.5070704@suse.de>
Date:	Wed, 27 Aug 2014 16:31:21 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	Christoph Hellwig <hch@...radead.org>,
	"K. Y. Srinivasan" <kys@...rosoft.com>
CC:	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 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.

And I really do _not_ want to do this automatically as the device 
might be busy due to various reasons (think of multipathing).
It tooks us ages to get this working with FC, and we finally settled 
to have a soft-remove implemented in the transport class.
And we still have issues with SAS HBAs, where at least the standard 
defines a mechanism. Trying this in the SCSI midlayer itself
is the road to disaster.

If we were to attempt this we would need to lift the dev_loss_tmo 
mechanism from the FC transport layer and make this a generic
facility for every HBA. But this is quite some work.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@...e.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-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/