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