linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: Matthew Wilcox <matthew@wil.cx>,
	Matthew Wilcox <willy@linux.intel.com>,
	linux-scsi@vger.kernel.org, "Moore, Eric" <Eric.Moore@lsi.com>
Subject: Re: [PATCH 1/3] SCSI: Make cmd_serial_number an atomic
Date: Sun, 03 Apr 2011 15:54:01 -0400	[thread overview]
Message-ID: <1301860442.2631.43.camel@mulgrave.site> (raw)
In-Reply-To: <20110403133306.GA22172@infradead.org>

On Sun, 2011-04-03 at 09:33 -0400, Christoph Hellwig wrote:
> On Sun, Apr 03, 2011 at 07:15:43AM -0600, Matthew Wilcox wrote:
> > Hm, yeah, it looks like it's only used for checking whether the command
> > we're aborting is the same command we're using to do the aborts.  In
> > which case, can't we simply do this?  Eric?
> 
> A similar question also applies for the old fusion driver.  There it
> even compares the serial number with one taken from the same scsi_cmnd
> in the same function.  If we could reuse a scsi_cmnd while in the
> ->eh_abort handler for fusion it would have to seriously mess up it's
> locking and lifetime rules.

Well, I think there's method in the madness for the old driver.  What it
seems to worry about is that the command gets reissued after the abort
because the abort routine sleeps.  If the reissue occurred, the same
command could be on the active list with a different serial number.

The theory is currently bogus because we halt all activity on the host
while error handler porcessing is active and the reissue won't occur
until after the abort routine returns.  Although if we did running error
handling, problems like this would arise ...

The new code seems to be an incorrect extract from the old code, so both
can currently go.

James



      reply	other threads:[~2011-04-03 19:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-01 20:20 [PATCH 1/3] SCSI: Make cmd_serial_number an atomic Matthew Wilcox
2011-04-02 13:36 ` Christoph Hellwig
2011-04-02 13:51   ` James Bottomley
2011-04-02 18:10   ` Jeff Garzik
2011-04-02 21:02   ` Matthew Wilcox
2011-04-03 11:00     ` Christoph Hellwig
2011-04-03 12:14       ` James Bottomley
2011-04-03 13:15       ` Matthew Wilcox
2011-04-03 13:33         ` Christoph Hellwig
2011-04-03 19:54           ` James Bottomley [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=1301860442.2631.43.camel@mulgrave.site \
    --to=james.bottomley@suse.de \
    --cc=Eric.Moore@lsi.com \
    --cc=hch@infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=willy@linux.intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).