From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ying Chu <jasonchu@marvell.com>
Cc: linux-scsi@vger.kernel.org, jeff@garzik.org, Tejun Heo <tj@kernel.org>
Subject: RE: libsas error-handling completion issue.
Date: Sun, 15 Mar 2009 09:14:31 -0500 [thread overview]
Message-ID: <1237126471.4376.10.camel@localhost.localdomain> (raw)
In-Reply-To: <FE3F06125A99254E8D92161AA4569C6F0687BD47@sc-exch02.marvell.com>
On Sat, 2009-03-14 at 21:02 -0700, Ying Chu wrote:
> >So, let me explain how the SAS_TASK_STATE_ABORTED works. It's actually the mediating flag in how completions are handled. There are two ways through ->task_done() depending on the state of this flag. If this flag is set, it means
> > that libsas owns the task and ->task_done() may not free it. Conversely if the timeout fires it checks the flags and if SAS_TASK_STATE_DONE is set, it returns BLK_EH_HANDLED because presumably the mid-layer will soon see it.
>
> What I meant is the corner case where interrupt is fired and the
> sas_task returned back at the monment but before sas_scsi_find_task()
> got invoked and set SAS_TASK_STATE_DONE flag. As in
> asd_task_tasklet_complete() routine, it will check if the
> STATE_ABORTED is set, if so, it doesn't invoke task_done() routine.
> Still returned to the strategy handler, sas_scsi_find_task() will try
> to abort the task and find it has been finished with STATE_DONE set,
> so it return TASK_IS_DONE and call sas_eh_finish_cmd(), where it unset
> the TASK_ABORTED flag and call task_done(). Noticed that in
> sas_eh_finish_cmd(), we call scsi_eh_finish_cmd() which will add the
> cmd to sas_ha->eh_done(), and in the coming flush_done_q it will be
> retried or finished again.
I'm still not quite seeing what you think the problem is. Is it that
task_done() calls scsi_cmnd->scsi_done(), in which case you think
there's a double completion? That's fixed in the block layer:
scsi_done() is blk_complete_request() which does nothing if the request
has a completion set and the block layer sets the completion when the
timeout fires.
James
James
next prev parent reply other threads:[~2009-03-15 14:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 6:44 libsas error-handling completion issue Ying Chu
2009-03-14 17:19 ` James Bottomley
2009-03-15 4:02 ` Ying Chu
2009-03-15 14:14 ` James Bottomley [this message]
[not found] ` <FE3F06125A99254E8D92161AA4569C6F029F0621@sc-exch02.marvell.com>
2009-03-15 17:13 ` 答复: " 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=1237126471.4376.10.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=jasonchu@marvell.com \
--cc=jeff@garzik.org \
--cc=linux-scsi@vger.kernel.org \
--cc=tj@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.