Well, what comes to mind immediately is two things.
First, does scsiglue.c's abort_command really need to handshake with the
code in usb.c?  If not, just get rid of the down and its matching up.
Second, this code (in scsi_error.c):
      774         spin_lock_irqsave(&io_request_lock, flags);
      775         rtn = SCpnt->host->hostt->eh_abort_handler(SCpnt);
      776         spin_unlock_irqrestore(&io_request_lock, flags);
seems like a real shotgun approach.  Get rid of the spinlock stuff, and
make sure that the abort handlers lock io_request_lock themselves if
they need it.  Of course, this would require changes to all the scsi
drivers.
I don't work with the kernel that much, so really I'm hoping somebody
else can suggest the fix - that's why I posted it in the first place. 
I'll cc this to the mailing lists, in the hope that somebody will have
an idea.
-- 
                                        -bwb
                                        Brent Baccala
                                        baccala@freesoft.org
==============================================================================
       For news from freesoft.org, subscribe to announce@freesoft.org:
   
mailto:announce-request@freesoft.org?subject=subscribe&body=subscribe
==============================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/