Matthew Dharm wrote:
>
> Brent --
>
> As the module maintainer, I'm very intereted in your analysis.....
>
> Of course, I'm interested in knowing how the command_abort function can be
> made safe -- I think there are already patches in the 2.4.8 kernel which
> should fix the cause of this function getting called.
>
> Any ideas on how to fix this issue?
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/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:40 EST