From: James Bottomley <jbottomley@parallels.com>
To: "bvanassche@acm.org" <bvanassche@acm.org>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"hch@infradead.org" <hch@infradead.org>,
"hare@suse.de" <hare@suse.de>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"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 10:21:32 +0000 [thread overview]
Message-ID: <1401186086.14454.43.camel@dabdike> (raw)
In-Reply-To: <5384541B.1010400@acm.org>
On Tue, 2014-05-27 at 11:00 +0200, Bart Van Assche wrote:
> On 05/27/14 10:23, James Bottomley wrote:
> > On Tue, 2014-05-27 at 09:49 +0200, Bart Van Assche wrote:
> >> When reading the source code in scsi_error.c it's easy to overlook that
> >> scmd_eh_abort_handler(), scsi_abort_command() and scsi_eh_scmd_add() are
> >> all invoked for requests in which the REQ_ATOM_COMPLETE bit has been
> >> set.
> >
> > I really don't like this entanglement of state of block and SCSI.
> > "complete" in block terms isn't the same as in SCSI terms. The
> > REQ_ATOM_COMPLETE flag is fully internal to block and indicates that
> > we've taken over processing the command and any completions into block
> > get ignored. This is for the possible race between timeout and inbound
> > command completion. If you start coding SCSI assertions in terms of it,
> > you're entangling layers that should be separate.
> >
> > The assertion in SCSI terms is that abort and ->done cannot race.
>
> Recent e-mail threads on the linux-scsi mailing list have shown that it
> is easily overlooked which error handler functions are called only for
> requests marked by the block layer as "complete" and hence cannot race
> with scsi_softirq_done(). So far my proposals for how to improve the
> documentation of how this race is avoided were rejected. Do you perhaps
> have a proposal of how this should be documented properly ?
Um, if that's your goal, then I don't see how adding a
WARN_ON_ONCE(!blk_rq_completed(scmd->request));
makes it clear that timeout and the softirq cannot race.
I suppose for me, it's just an obvious systems assertion since every
command must be in a defined state for the state model, either a command
has timed out or it's in normal completion. But since we inherit this
race mediation from block, isn't that the place to document it if people
are confused?
I could also see us one day extending the TMF capability to abort any
running command, which would make even an assertion of block timed out
or completed invalid.
James
next prev parent reply other threads:[~2014-05-27 10:21 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 [this message]
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
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=1401186086.14454.43.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).