On Thu, 5 Jan 2012, Matthew Dharm wrote: > So, I guess the situation really comes down to this: The current code > prevents anyone from reporting anything higher than SCSI_2, but lower > values are allowed. Here, we have a device that needs to report > higher than SCSI_2. Allowing reporting of values higher than SCSI_2 > may cause issues with READ_CAPACITY (but we have an unusual_devs flag > for that case), REPORT_LUNS (handled by your patch by globally > blocking REPORT_LUNS for all usb-storage devices), reading VPD pages, > and possible st_mod logic. Right. > Hrm... do we have any idea how devices respond to reading various VPD pages? I don't remember anything. But there is a comment in sd.c about some USB devices crashing when they receive those commands. > I'm not really concerned about st_mod. There are just too few USB > tape devices out there anymore. Any complaints we get could be dealt > with on a device-by-device basis with special flags, if necessary. > > BUT, without some assurances that devices won't fall over when asked > for VPD pages, I'm hesitant to go forward. How about this: what if > you change the name of the flag from "no_report_luns" to > "likely_braindead_target" (you can pick a different name if you want) > and then use that to block REPORT_LUNS as well as the enhanced VPD > retrieval? With this plan, devices reporting higher than SCSI_2 will > get commands formatted the way they want (no LUN bit-stuffing), but > will also not get commands that we're not positive they will accept. Sure, that ought to work. I'll update the patch. > The flip side is to go forward with your patch as planned, and if the > VPD issue becomes a problem, then add in a separate "don't get VPD > pages" flag later. Unless this VPD data is *really* important, I > would be inclined to not issue the command. A userspace tool could > always issue the command if the user wanted the info, and thus they > accept the responsibility for killing their device (until reset). I don't know how important that information is. It might matter for things like releasing regions on SSDs. If necessary, we can always add a new flag like you suggest. Alan Stern -- 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
