Re: strange USB storage failure with 2.6.29-rc2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 28 Jan 2009 11:54:39 -0500 (EST)
Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux