All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Jes Sorensen <jes@trained-monkey.org>
Cc: Adam Radford <aradford@3WARE.com>,
	"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>,
	"'linux-scsi@vger.kernel.org'" <linux-scsi@vger.kernel.org>
Subject: Re: [patch] 3Ware 64 bit locking issues
Date: Thu, 23 Aug 2001 08:59:02 +0200	[thread overview]
Message-ID: <20010823085902.M604@suse.de> (raw)
In-Reply-To: <53B208BD9A7FD311881A009027B6BBFB9EAE47@siamese> <m3g0ajncgh.fsf@trained-monkey.org>
In-Reply-To: <m3g0ajncgh.fsf@trained-monkey.org>

On Wed, Aug 22 2001, Jes Sorensen wrote:
> >>>>> "Adam" == Adam Radford <aradford@3WARE.com> writes:
> 
> Adam> Thanks for flags type fix and redundant pushf/popf fix.
> Adam> Regarding your question about the error handling routines, the
> Adam> 3ware driver uses the new style scsi error handling, so looking
> Adam> through scsi_error.c, all calls to
> Adam> hostt->eh_abort_handler() and hostt->eh_host_reset_handler() are
> Adam> wrapped with a spin_lock_irqsave(&io_request_lock, flags) and
> Adam> spin_unlock_irqrestore(&io_request_lock, flags) so they should
> Adam> be okay.
> 
> Hmm ok. However, since Jens is working on killing the io_request_lock
> so something will need to get done when that happens.
> 
> Jens, what is the strategy for that?

Lots of the lower level hooks are done with io_request_lock required,
the only one I've killed so far is ->detect() and that was mainly
because it didn't fit with the new scheme (per-host locking, host not
inited at this time). IMO it was a mistake to ever grab io_request_lock
(or any other lock, for that matter) before calling into the lower
levels -- it's not very clean and it makes progressing to a better
locking structure harder.

Basically we want to move the locking down a notch, so the mid layer is
not responsible for providing reentrance protection for the low level
drivers. It will be painfull...

-- 
Jens Axboe


  reply	other threads:[~2001-08-23  6:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53B208BD9A7FD311881A009027B6BBFB9EAE47@siamese>
2001-08-22 19:04 ` [patch] 3Ware 64 bit locking issues Jes Sorensen
2001-08-23  6:59   ` Jens Axboe [this message]
2001-08-16  4:21 jes

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=20010823085902.M604@suse.de \
    --to=axboe@suse.de \
    --cc=aradford@3WARE.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.