> If your theory is that the hardware just returned a bogus value, this > isn't the right way to sanitise it because the chances are you'll > complete the wrong command and cause corruption: you'd have to halt the > entire system at that point. Also, I don't understand why you think the > value should only be 0-31? The size of variable allocated there is for > SCBs up to 243, no idea why, since some of the allocation routines will > search up to 256. However, safety from overrun should be guaranteed at > least at the system level by the can_queue value. I agree. If the hardware returns a bogus value, it immediately would crash. Would a more appropriate patch be checking within the ORC_MAXQUEUE range and flagging an error? > > Double checking hardware values isn't something we habitually do unless > there's a known reason for it (like the state machine does throw bogus > values with a defined recovery procedure). We definitely don't run in > the mode where you can't trust your hardware. > Hardware can fail for multiple reasons. Furthermore, such bugs are security vulnerabilities too in the case of virtual hardware or USB drivers where such values can be faked. The article in my patch gives more details. http://lwn.net/Articles/479653/ Thanks, Asim -- To unsubscribe from this list: 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
