linux-kernel - Re: [PATCH 1/1] scsi: retrieve cache mode using ATA

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: <1323848398.3063.12.camel@dabdike>
Date:	Wed, 14 Dec 2011 11:39:58 +0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Amit Sahrawat <amit.sahrawat83@...il.com>
Cc:	Jeff Garzik <jeff@...zik.org>, Namjae Jeon <linkinjeon@...il.com>,
	Nam-Jae Jeon <namjae.jeon@...sung.com>,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] scsi: retrieve cache mode using ATA_16 if normal
 routine fails

On Wed, 2011-12-14 at 09:14 +0530, Amit Sahrawat wrote:
> Just to add a thought - this issues is not related with ATA, this is
> primarily related with HDD's with a USB interface i.e., SCSI <-> USB.
> And, when I check my kernel config, CONFIG_ATA is not selected,
> libata-scsi - this gets compiled only in case CONFIG_ATA is on.
> Are these two things inter-related?

OK, so what you're telling us is that you're trying to correct a
deficiency in a SATL inside a USB device?  The device itself is ATA but
it doesn't use our libata connectors.

I think in that case, the best way forwards is a mini-SATL correction
layer within USB storage.  USB storage is certainly the place to
black/white list whether this should be done.  ATA_16 is a bit of a
dangerous command to be throwing around because it's known to crash
various USB devices (and some old SCSI ones might even choke on it).

depending on how big this SATL ends up being we should consider whether
it should share processing with the libata SATL.  If it's just a single
mode sense, my instinct is that it's probably OK to implement separately
(however, you need to use the libata headers ... no duplication of
libata opcodes and status defines like you had in the original SCSI
patch).  If there are more commands to correct on the way, it might be
better as shared code.

James

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