From: Brent Baccala <baccala@freesoft.org>
To: Matthew Dharm <mdharm@one-eyed-alien.net>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linux-usb-devel <linux-usb-devel@lists.sourceforge.net>
Subject: Re: Problem with usb-storage using HP 8200 external CD-ROM burner
Date: Mon, 06 Aug 2001 15:49:46 -0400 [thread overview]
Message-ID: <3B6EF4DA.8899E1D3@freesoft.org> (raw)
In-Reply-To: <3B68FB0C.5BC83115@freesoft.org> <20010806014626.K24225@one-eyed-alien.net>
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
==============================================================================
next prev parent reply other threads:[~2001-08-06 19:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-02 7:02 Problem with usb-storage using HP 8200 external CD-ROM burner Brent Baccala
[not found] ` <20010806014626.K24225@one-eyed-alien.net>
2001-08-06 19:49 ` Brent Baccala [this message]
2001-08-07 3:17 ` Matthew Dharm
2001-08-07 7:33 ` Jens Axboe
2001-08-07 15:09 ` Brent Baccala
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3B6EF4DA.8899E1D3@freesoft.org \
--to=baccala@freesoft.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=mdharm@one-eyed-alien.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.