Al Viro wrote:
OK, I think I've seen one that does it. Behold the lossage: * bugger does, indeed, report itself to be type 0 * OK, says sd_read_cache_type(). Page 8 for you, then. * so called "SCSI device" spits out... <drumroll> RBC page 6. Sans mode page headers. So we see 0x86 0x0b where the data length should've been. And bytes 3 and 2 of device size where the block descriptors size should've been. Since sd.c doesn't expect that level of idiocy (it should, but...) we adjust length down from ~34000 to 20 _and_ blindly add block descriptors size. Or what we assume to be one. Then we proceed to call scsi_mode_sense() with buffer created by kmalloc(512, GFP_DMA) and len... well, anywhere up to 64Kb. One of the first things it does is memset(buffer, 0, len).
Thanks a lot for the investigation & explanation.
That's an Initio bridge, BTW. I suspect that the best we can do is to blacklist the little shit with "don't trust that one, it's really type 14". If it reacts to request for page 6 in a saner fashion, that is...
2.6.16-rc4-mm1's sbp2 already detects most of the Initio bridges and flags them with skip_ms_page_8. It does so based on the firmware_revision config ROM entry. This seems to catch most Initio bridges but there was at least one report of a different firmware_revision key value. However all of them feature "Initio" as vendor string. I suppose I should let sbp2_slave_configure check for this string in sdev->vendor and for sdev->type == TYPE_DISK, then bend sdev->type to TYPE_RBC. (Or set skip_ms_page_8; I will check how my disk behaves when forced to TYPE_RBC...)
-- Stefan Richter -=====-=-==- --=- =-=-= http://arcgraph.de/sr/ - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
