On Wed, 28 Jan 2009 12:47:45 -0500 (EST) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 28 Jan 2009, Dirk Hohndel wrote: > > > > > The other one is "why isn't the USB stack filtering that command when > > > > it comes down from SCSI?" > > > > > > The USB stack doesn't do any filtering. The SCSI stack is supposed to > > > know what commands should and should not be sent. > > > > > > Furthermore, it seems quite likely this command was sent by userspace, > > > not by the SCSI stack -- in which case the program is supposed to know > > > what commands it shouldn't send. > > > > Not sure I agree with that logic. If the USB stack KNOWS that > > non-removable devices get upset by this command, then it would be > > appropriate for it to filter those out - to protect from bugs as much > > as to protect from denial of service attacks. > > Part of the problem is that many devices claim to have removable media > when in fact they don't. And going back to your first email message, I > see that your device is one of them: > > > Jan 22 13:49:53 dhohndel-mobl4 kernel: [ 46.329437] sd 4:0:0:0: [sdb] Attached SCSI \ > > removable disk > ^^^^^^^^^ > > In any case, usb-storage is just a transport. It sends commands from > higher up (the SCSI stack) to a USB device. It filters the commands as > little as possible. In other words, don't blame the messenger for > delivering a bad message. I had missed that part that the stick claimed to be a removable device (it is, in a sense, but then it shouldn't balk at being ejected). > > > > Maybe we need to bring such code back? > > > > > > Definitely not! The correct approach to is to find the program > > > responsible for sending that command and fix it. > > > > That's definitely something we should do (and I will continue to hunt > > this down), but my logic above still applies. I think this should have > > a WARN_ON around it, but should still be filtered. > > Nope. How would people feel when they triggered your WARN_ON every > time they ejected a disc from their USB CD-ROM drive? I agree - see above. > > > Or you could guess that the offending command is sent by a > > > system/desktop utility, such as hal or udev. Have you added or changed > > > any software in that area recently? > > > > As I mentioned, I tried this in runlevel 3 - no desktop running. > > Both hal and udev would still be running in level 3. I'll poke at this some more. /D -- Dirk Hohndel Intel Open Source Technology Center -- 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