linux-kernel - Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

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: <4A6DCA7F.4080006@panasas.com>
Date:	Mon, 27 Jul 2009 18:40:47 +0300
From:	Boaz Harrosh <bharrosh@...asas.com>
To:	"Martin K. Petersen" <martin.petersen@...cle.com>
CC:	Matthew Wilcox <matthew@....cx>,
	Tarkan Erimer <tarkan.erimer@...knet.net.tr>,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some
 USB Disks

On 07/27/2009 06:19 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh <bharrosh@...asas.com> writes:
> 
> Boaz> Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must
> Boaz> be supported but you are saying it's only SBC2/SPC3. So I guess
> Boaz> there is nothing else we can do.
> 
> Yes, EVPD must be supported.  USB-ATA bridge firmware writers are
> dyslexic.  Film at 11.
> 
> What I'm saying is that *our* reason for sending out extended inquiry
> appeared in SBC2 (block limits VPD).  So there is no point in asking
> devices older than that.
> 
> The fact that this fixes the problem for Tarkan's crappy disk is a
> (quasi-intentional) side effect.  My patch simply tries to be
> conservative about asking for those pages.
> 
> 
> Boaz> What I hate about all this is that in USB the scsi_level is hard
> Boaz> coded at the driver, without actually been able to probe the
> Boaz> device about it.
> 
> Huh, what?
> 

Look in drivers/usb/storage::slave_configure

		/* Some devices report a SCSI revision level above 2 but are
		 * unable to handle the REPORT LUNS command (for which
		 * support is mandatory at level 3).  Since we already have
		 * a Get-Max-LUN request, we won't lose much by setting the
		 * revision level down to 2.  The only devices that would be
		 * affected are those with sparse LUNs. */
		if (sdev->scsi_level > SCSI_2)
			sdev->sdev_target->scsi_level =
					sdev->scsi_level = SCSI_2;

So the scsi_level is hard coded to very low.
Or am I reading this code wrong and it is only triggered for some but not
all devices?

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