On Mon, Aug 06, 2001 at 03:49:46PM -0400, Brent Baccala wrote:
> Matthew Dharm wrote:
> > Of course, I'm interested in knowing how the command_abort function can=
> > 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.
Unfortunately, it does. The SCSI layer seems to believe that once we've
returned from the abort_command() routine, the driver is in a position to
accept a new command. Thus, some level of handshaking is necessary.
> Second, this code (in scsi_error.c):
> 774 spin_lock_irqsave(&io_request_lock, flags);
> 775 rtn =3D 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
Hrm... perhaps I could just unlock that spinlock and then re-lock it before
returning. Anyone have a clue if this would work?
Matthew Dharm Home: mdharm-usb@one-eyed-alien.=
Maintainer, Linux USB Mass Storage Driver
Would you mind not using our Web server? We're trying to have a game of=20
User Friendly, 5/11/1998
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/