On Wed, Aug 11, 2010 at 05:34:43PM -0700, Matthew Dharm wrote: > On Wed, Aug 11, 2010 at 04:43:56PM -0700, Greg KH wrote: > > Ok, I see the argument is valid for both sides. > > > > What do others think? Mathew, any thoughts? > > My only thought is that we've tried extensive command filtering in the > past. It seemed like every 6 months we were back, tweaking things that had > already been fixed. I don't like fixing the same bug multiple times. > > My general theory is that "you shouldn't send a command to a device that it > can't handle". I recognize that this puts the burden on the SCSI drivers > and the userspace application folks. I also think that a userspace app, > with sufficient privlidges, *should* be able to send any command it wants > to the hardware. It is the app's power, privlidge, and responsibility to > get it right or deal with the consequences. > > If we filter at the usb-storage level, we take away that power. > > For example, suppose 6 months from now someone discovers that Windows does, > in fact, use the offending command, but this time with a set of parameters > which seems to work. Why should we prevent a userspace app from using that > knowledge? And before you say "that will never happen," recognize that it > already did -- we spent quite a bit of time making sd_mod generate > MODE_SENSE commands (to check for write-protect status) the way the Redmond > OS does (for maximum compatibility). That was a long time ago, but it is > worth noting that since doing that, write-protect detection has > *stayed*fixed* (i.e. devices no longer crash wholesale during detection). > > In general, I take the stance that we should allow userspace to do whatever > it wants. The kernel-level drivers should generally avoid doing things > which are likely to send devices over-the-edge (c.f. MODE_SENSE mentioned > above), but the drivers should not intervene in a userspace-generated > command. > > For example, does any HBA filter out the SCSI low-level format command? > It's really never needed now (hasn't been for what, 15 years?). Should we > filter that, because issuing it to a device will cause irreversable data > loss, and the HBA can identify devices (i.e. disks) which will react badly > to the command? > > Yes, that last paragraph is a hyperbolic straw-man. But the point is that, > to my knowledge, every "pass-through" driver (i.e. drivers that move > commands/data from one driver above to another driver below) in the kernel > does as *little* filtering as necessary, if any at all. > > Finally, I want to address one point of clarification: With the exception > of INQUIRY, usb-storage does not intercept and cancel any commands. > Usb-storage does re-write the results of a few commands (auto-sense, read > capacity) in an attempt to translate the data coming back from the device > into the format that SCSI expects it to be in. But, we do not have a > command filtering infrastructure. Ok, that convinces me. And these patches are ok with you, right? James, any further objections? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
