From: James Bottomley <jbottomley@parallels.com>
To: "pbonzini@redhat.com" <pbonzini@redhat.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"hch@infradead.org" <hch@infradead.org>,
"hare@suse.de" <hare@suse.de>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"jdl1291@gmail.com" <jdl1291@gmail.com>
Subject: Re: [PATCH 2/3] block: Introduce blk_rq_completed()
Date: Tue, 27 May 2014 11:57:41 +0000 [thread overview]
Message-ID: <1401191860.14454.65.camel@dabdike> (raw)
In-Reply-To: <53847C62.9070704@redhat.com>
On Tue, 2014-05-27 at 13:52 +0200, Paolo Bonzini wrote:
> Il 27/05/2014 13:26, James Bottomley ha scritto:
> >> You could use a different mechanism than a softirq to tell the abort
> >> were successful, for example by overriding scsi_done. But with respect
> >> to the block layer, the mechanics of avoiding the race and double-free
> >> would probably be the same.
> >
> > I think there's some confusion about what the race and double free is:
> > It only occurs with timeouts. In a timeout situation, the host had
> > decided it's not waiting any longer for the target to respond and
> > proceeds to error recovery. At any time between the host making this
> > decision up to the point it kicks the target hard enough to clear all
> > in-flight commands, the target may return the command. If we didn't
> > have some ignore function on command completions while we're handling
> > errors, this would lead to double completion.
> >
> > If we decided to allow arbitrary aborts of running commands, we would
> > send a TMF in during the normal (i.e. un timed out) command period.
> > Because there's no timeout involved, there's no double free problem.
> > The race in this case is whether the abort catches the command or not
> > and to mediate that race we need the normal status return.
>
> I'm not sure why "no timeout" implies "no double free". There would
> still be a race between the interrupt handler and softirq on one side,
> and the abort handler on the other.
You're assuming the current error handling after timeout methodology.
If we allow arbitrary TMFs, that doesn't hold because we have to wait
for the command completion.
James
next prev parent reply other threads:[~2014-05-27 11:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-26 15:12 Make SCSI error handler code easier to understand Bart Van Assche
2014-05-26 15:14 ` [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler Bart Van Assche
2014-05-26 15:15 ` [PATCH 2/3] block: Introduce blk_rq_completed() Bart Van Assche
2014-05-26 15:27 ` James Bottomley
2014-05-27 7:49 ` Bart Van Assche
2014-05-27 7:52 ` hch
2014-05-27 8:00 ` James Bottomley
2014-05-27 8:23 ` James Bottomley
2014-05-27 9:00 ` Bart Van Assche
2014-05-27 10:21 ` James Bottomley
2014-05-27 10:47 ` Paolo Bonzini
2014-05-27 10:59 ` James Bottomley
2014-05-27 11:13 ` Paolo Bonzini
2014-05-27 11:26 ` James Bottomley
2014-05-27 11:52 ` Paolo Bonzini
2014-05-27 11:57 ` James Bottomley [this message]
2014-05-27 5:40 ` Hannes Reinecke
2014-05-26 15:23 ` [PATCH 1/3] Remove two cancel_delayed_work() calls from the error handler Paolo Bonzini
2014-05-26 15:25 ` James Bottomley
2014-05-27 8:06 ` Bart Van Assche
2014-05-27 8:09 ` James Bottomley
2014-05-27 8:36 ` Bart Van Assche
2014-05-27 8:56 ` James Bottomley
2014-05-27 9:06 ` Paolo Bonzini
2014-05-27 5:40 ` Hannes Reinecke
2014-05-27 6:08 ` Bart Van Assche
2014-05-27 6:22 ` Hannes Reinecke
2014-05-26 15:15 ` [PATCH 3/3] Make SCSI error handler code easier to understand Bart Van Assche
2014-05-27 5:42 ` Hannes Reinecke
2014-05-28 20:15 ` Joe Lawrence
2014-05-29 11:33 ` James Bottomley
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=1401191860.14454.65.camel@dabdike \
--to=jbottomley@parallels.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=jdl1291@gmail.com \
--cc=linux-scsi@vger.kernel.org \
--cc=pbonzini@redhat.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).