Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel <hohndel@infradead.org>]

On Wed, 28 Jan 2009 12:47:45 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> 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