From: Luben Tuikov <luben_tuikov@adaptec.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Christoph Hellwig <hch@infradead.org>,
James Bottomley <James.Bottomley@steeleye.com>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] Re: sleeping in scsi EH
Date: Fri, 27 May 2005 11:01:01 -0400 [thread overview]
Message-ID: <4297362D.6040504@adaptec.com> (raw)
In-Reply-To: <4296FA61.4010003@pobox.com>
On 05/27/05 06:45, Jeff Garzik wrote:
> Christoph Hellwig wrote:
>
>>On Fri, May 27, 2005 at 04:37:29AM -0400, Jeff Garzik wrote:
>>
>>
>>>Christoph Hellwig wrote:
>>>
>>>
>>>>You can sleep in them. You must however release the host lock and enable
>>>>irqs first and reverse that before returning. The error handlers don't
>>>>need the host lock, but we're stuck with the unfortunate calling convention
>>>>for now.
>>>
>>>Why are we stuck with this calling convention, when everyone who cares
>>>circumvents it?
>>
>>
>>Because no one found the time to do a full transition yet. If you want to
>>update all scsi drivers feel free. One patch per method please.
>
>
> Something like the attached?
I like it very, _very_ much.
That is, what is the point to have EH in the first place (from a
kernel thread) when a lock is held and irqs are off? (no sleeping)
Might as well go back to abort()... ;-) The whole point of
EH is so that LLDD can sleep waiting possible for TMFs to return.
In general I don't like to see SCSI Core imposed locking onto the
LLDDs. LLDDs should take care of their own locking as should SCSI Core.
Next: off with the host_lock. ;-)
> * Returns SUCCESS if command aborted else FAILED
> *
> - * Locks: struct Scsi_Host::host_lock held (with irqsave) on entry
> - * and assumed to be held on return.
> + * Locks: None held. EH context.
> *
> * Calling context: kernel thread
Is it possible to mention explicitly that sleeping is allowed
and encouraged while waiting for TMFs to return and
to change "LLD", "Low Level Driver" -- I've seen those
on the streets, either drunks or bad drivers, --
to "LLDD", "Low Level _Device_ Drivers"?
Luben
prev parent reply other threads:[~2005-05-27 15:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 2:26 sleeping in scsi EH Jeff Garzik
2005-05-27 7:09 ` Christoph Hellwig
2005-05-27 8:37 ` Jeff Garzik
2005-05-27 8:42 ` Christoph Hellwig
2005-05-27 10:45 ` [PATCH] " Jeff Garzik
2005-05-27 10:52 ` Christoph Hellwig
2005-05-27 17:53 ` Jeff Garzik
2005-05-27 14:10 ` Brian King
2005-05-27 14:17 ` Matthew Wilcox
2005-05-27 14:35 ` Brian King
2005-05-27 16:54 ` Jeff Garzik
2005-05-27 17:35 ` Brian King
2005-05-27 15:01 ` Luben Tuikov [this message]
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=4297362D.6040504@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=James.Bottomley@steeleye.com \
--cc=hch@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-scsi@vger.kernel.org \
/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.