Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel <hohndel@infradead.org>]

On Wed, 28 Jan 2009 11:54:39 -0500 (EST)
Alan Stern <stern@rowland.harvard.edu> wrote:

> > > So the real question is: Who is responsible for sending that Eject 
> > > command?  It certainly isn't usb-storage or any other part of the USB 
> > > stack.  Maybe something in the SCSI disk driver or maybe a user 
> > > program.
> > 
> > That's one valid question... maybe someone on the linux-scsi list can
> > sched some light onto this? Are there SCSI specific debugging options I
> > should turn on?
> 
> I don't see anything in the sd driver that could have done it.  And I 
> don't know where else in the kernel it would have come from -- which is 
> not to say that I'm familiar with every part of the kernel!

I did some greping and couldn't find anything suspicious, either.

> > 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.

> > 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.
 
> Unfortunately, I don't know any easy way to identify programs as they 
> send SCSI commands.  I suppose you could add some debugging statements 
> in block/scsi_ioctl.c and drivers/scsi/sg.c to monitor all those 
> commands as they come in from userspace.  There are several different 
> pathways for this, and the command could come from any of them.

That's why I copied the scsi list, hoping that they have some tools /
ideas how to do this.
 
> 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. And
this is on an (as far as I can remember) unmodified F10 64bit... so I'm
surprised that I appear to be the only one reporting this; which of
course makes me challenge my own "unmodified" statement :-)

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center