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
