linux-kernel - Re: scanning for LUNs

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 for Android: free password hash cracker in your pocket

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

Message-ID: <5162D73E.4000906@suse.de>
Date:	Mon, 08 Apr 2013 16:42:06 +0200
From:	Hannes Reinecke <hare@...e.de>
To:	KY Srinivasan <kys@...rosoft.com>
Cc:	James Bottomley <jbottomley@...allels.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
	"ohering@...e.com" <ohering@...e.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: scanning for LUNs

On 04/04/2013 07:12 PM, KY Srinivasan wrote:
> 
> 
>> -----Original Message-----
>> From: James Bottomley [mailto:jbottomley@...allels.com]
>> Sent: Thursday, April 04, 2013 11:15 AM
>> To: KY Srinivasan
>> Cc: gregkh@...uxfoundation.org; linux-kernel@...r.kernel.org;
>> devel@...uxdriverproject.org; ohering@...e.com; hch@...radead.org; linux-
>> scsi@...r.kernel.org
>> Subject: Re: scanning for LUNs
>>
>> On Thu, 2013-04-04 at 08:12 -0700, K. Y. Srinivasan wrote:
>>> Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in function
>>> __scsi_scan_target()):
>>>
>>>         /*
>>>          * Scan LUN 0, if there is some response, scan further. Ideally, we
>>>          * would not configure LUN 0 until all LUNs are scanned.
>>>          */
>>>         res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan, NULL);
>>>         if (res == SCSI_SCAN_LUN_PRESENT || res ==
>> SCSI_SCAN_TARGET_PRESENT) {
>>>                 if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
>>>
>>>
>>> So, if we don't get a response while scanning LUN0, we will not use
>>> scsi_report_lun_scan().
>>> On Hyper-V, the scsi emulation on the host does not treat LUN0 as
>>> anything special and we
>>> could have situations where the only device under a scsi controller is
>>> at a location other than 0
>>> or 1. In this case the standard LUN scanning code in Linux fails to
>>> detect this device. Is this
>>> behaviour expected? Why is LUN0 treated differently here. Looking at
>>> the scsi spec, I am not sure
>>> if this is what is specified. Any help/guidance will be greatly
>>> appreciated.
>>
>> Why don't you describe the problem.  We can't scan randomly a bunch of
>> LUNs hoping for a response (the space is 10^19).  SAM thinks you use
>> LUNW for this, but that's not well supported.  We can't annoy USB
>> devices by probing with REPORT LUNS, so conventionally most arrays
>> return something for LUN0 even if they don't actually have one (That's
>> what the peripheral qualifier codes are supposed to be about).  We
>> translate PQ1 and PQ2 to SCSI_SCAN_TARGET_PRESENT, which means no LUN,
>> but there is a target to scan here.
>>
>> If you're sending back an error to an INQUIRY to LUN0, then you're out
>> of spec.  The SCSI standards say:
>>
>>         SPC3 6.4.1: In response to an INQUIRY command received by an
>>         incorrect logical unit, the SCSI target device shall return the
>>         INQUIRY data with the peripheral qualifier set to the value
>>         defined in 6.4.2. The INQUIRY command shall return CHECK
>>         CONDITION status only when the device server is unable to return
>>         the requested INQUIRY data
> 
> Thanks James. I will further investigate the issue on our platform.
> 
Or check if you can use W_LUN for scanning.
I've done a patchset for this (check the mailing list).

Using W_LUN is precisely for this type of setup.

(And would provide me with another scenario for using W_LUNs :-)

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/