[8262] in linux-scsi channel archive
Re: queueing commands and IRQs?
daemon@ATHENA.MIT.EDU (Kurt Garloff)
Sun Feb 27 19:09:29 2000
Date: Mon, 28 Feb 2000 00:39:15 +0100
From: Kurt Garloff <garloff@suse.de>
To: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>
Cc: The Linux SCSI list <linux-scsi@vger.rutgers.edu>
Message-ID: <20000228003915.E26262@mobil.tue.nl>
Mail-Followup-To: Matthew Dharm <mdharm-scsi@one-eyed-alien.net>,
The Linux SCSI list <linux-scsi@vger.rutgers.edu>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
protocol="application/pgp-signature"; boundary="idY8LE8SD6/8DnRI"
In-Reply-To: <Pine.LNX.4.10.10002251519560.7808-100000@ziggy.one-eyed-alien.net>; from mdharm-scsi@one-eyed-alien.net on Fri, Feb 25, 2000 at 03:22:00PM -0800
--idY8LE8SD6/8DnRI
Content-Type: text/plain; charset=us-ascii
On Fri, Feb 25, 2000 at 03:22:00PM -0800, Matthew Dharm wrote:
> I think I know the answer to this, but if I'm wrong all sorts of bad will
> happen, so I figured I'd bother the experts to make sure. :)
>
> When the SCSI layers calls a host's command queue function, is there any
> possibility that the context will be interrupt context? Basically, I need
> to know if I need spin_lock() or spin_lock_irqsave(). The non-irq safe
> version is "much faster" (according to Linus in spinlock.txt).
There is a possibility that you are in IRQ context: You get a couple of
interrupts when the command is being processed by the device and on
completion, you call scsi_done (). The mid-layer may immediately call
queue_command() again to queue the nect cmnd.
This is true for the old exception handling. I think it was one of the
objectives to remove this behaviour in the new EH code, but I'm not sure
it's always accomplished. Eric Youngdale should be able to comment on that.
Anyway, I think you need to use the irq safe spinlock anyway, cause
otherwise you risk:
queue_command(): spinlock
IRQ -> irq handler: spinlock_irqsave() will deadlock!!
That's the normal scenario, at least if you just use one adapter specific
lock or the global io_request_lock.
BTW: The io_request_lock is being locked from mid-layer, except (obviously)
for the IRQ handler.
Hope this helps.
--
Kurt Garloff <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
--idY8LE8SD6/8DnRI
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1c- (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE4ubWjxmLh6hyYd04RAbtpAJ9fXExvHKBtzBGk1TP6HH4IVsWeTgCgqUqA
y1DsIoaYghsQN7V30egHGAo=
=ZHpF
-----END PGP SIGNATURE-----
--idY8LE8SD6/8DnRI--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
