Re: strange USB storage failure with 2.6.29-rc2

[Dirk Hohndel <hohndel@infradead.org>]

On Wed, 28 Jan 2009 17:59:11 +0000
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > > 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.
> 
> Well, I really don't think we want to get into vetting SCSI commands
> over SG_IO ... that would just trip us up on the enterprise (and
> probably never work anyway).

Yeah, I understand now and agree with you and Alan on that one...

> The problem is that hal wants to send its own SCSI commands over SG_IO.
> We've spent years trying to persuade it to put the crackpipe down and
> back away from the window ledge on this (because SCSI in the kernel
> knows better how to handle problem devices).  We have been having some
> limited success recently ... we keep enhancing what sysfs provides
> (safely) so that hal doesn't have to poke in with SG_IO unsafely.
> 
> If you can find out what the actual reason hal or whatever is doing
> this, we can have another go at them.

Any recommendations how to best approach debugging this? Attaching
strace to some processes before inserting the usb stick?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center