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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <12d86cf8a8c84ae787b8be0fa382fa29@SN2PR03MB061.namprd03.prod.outlook.com>
Date:	Mon, 8 Apr 2013 17:34:52 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Hannes Reinecke <hare@...e.de>
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



> -----Original Message-----
> From: Hannes Reinecke [mailto:hare@...e.de]
> Sent: Monday, April 08, 2013 10:42 AM
> To: KY Srinivasan
> Cc: James Bottomley; 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 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 :-)

Thanks Hannes. What is the status on this patch; is it planned for the next upstream release?

Regards,

K. Y
> 
> 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/