All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Bart Van Assche <bvanassche@acm.org>
Cc: James Bottomley <jbottomley@parallels.com>,
	Christoph Hellwig <hch@infradead.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	Joern Engel <joern@logfs.org>, Ewan Milne <emilne@redhat.com>,
	James Smart <james.smart@emulex.com>,
	Ren Mingxin <renmx@cn.fujitsu.com>,
	Roland Dreier <roland@purestorage.com>,
	Bryn Reeves <bmr@redhat.com>
Subject: Re: [PATCH 3/9] scsi: improved eh timeout handler
Date: Wed, 12 Jun 2013 08:42:18 +0200	[thread overview]
Message-ID: <51B8184A.6030303@suse.de> (raw)
In-Reply-To: <51B81685.7020204@acm.org>

On 06/12/2013 08:34 AM, Bart Van Assche wrote:
> On 06/11/13 20:57, James Bottomley wrote:
>> Actually, I think we can dump the workqueue altogether.  The only
>> reason
>> we need it is because the current abort handlers wait for the command
>> and return the completion state.  However, all LLDs are capable of
>> emitting TMFs at interrupt level, so if we separated the emit from
>> the
>> wait, we could simply do this sequence:
>>
>> on timeout, fire the abort from interrupt and mark the command as
>> having
>> an abort issued (possibly by adding a pointer to the abort task),
>> return
>> BLK_EH_RESET_TIMER.
>>
>> Now if the timeout fires again, assume the abort was unsuccessful and
>> escalate to LUN reset.
>>
>> This is fully asynchronous, fully tracked and doesn't rely on work
>> queues.
>>
>> The necessary additions for something like this are the from
>> interrupt
>> issue abort and LUN reset, which could just be additional
>> callbacks in
>> the host template.
> 
> Do we really need a new callback in the host template for a command
> abort that does not wait ? Several LLDs already have their own
> internal data structures for keeping track of the request state and
> can use these data structures to set a flag "command has been
> aborted". If aborting a command fails and the command completes that
> flag can then be used to avoid a second invocation of scsi_done().
> At least, that's what the SRP initiator already does today in
> srp_abort().
> 
Currently I'm playing around with this:

diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 4908480..498164a 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -174,6 +174,9 @@ struct scsi_host_template {
        int (* eh_bus_reset_handler)(struct scsi_cmnd *);
        int (* eh_host_reset_handler)(struct scsi_cmnd *);

+       int (* eh_send_abort)(struct scsi_cmnd *);
+       void (* eh_cancel_abort)(struct scsi_cmnd *);
+
        /*

'eh_send_abort' sends the TMF asynchronously; it is the drivers
responsibility to return the command to be aborted to the SCSI
midlayer after calling this function.
The return value is 'SUCCESS' if the TMF was sent or 'FAILED' if
sending the TMF failed. It does _not_ indicate the status of the TMF
itself, as this is done implicitly by returning the command with an
appropriate status.

'eh_cancel_abort' is optional, and can be called at any time after
'eh_send_abort' to cancel the TMF. After calling 'eh_cancel_abort'
neither the TMF nor the command must be considered valid from the LLDD.
'eh_cancel_abort' is for LLDDs requiring cleanups when aborting
TMFs. LLDDs not requiring any cleanup simply can not implement this
callback.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-06-12  6:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-10  7:40 [PATCHv2 0/9] New SCSI command timeout handler Hannes Reinecke
2013-06-10  7:40 ` [PATCH 1/9] scsi: move initialization of scmd->eh_entry Hannes Reinecke
2013-06-10  8:17   ` Christoph Hellwig
2013-06-10  7:40 ` [PATCH 2/9] blk-timeout: add BLK_EH_SCHEDULED return code Hannes Reinecke
2013-06-10  7:40 ` [PATCH 3/9] scsi: improved eh timeout handler Hannes Reinecke
2013-06-10  8:20   ` Christoph Hellwig
2013-06-10  9:00     ` Hannes Reinecke
2013-06-10 15:19       ` Jörn Engel
2013-06-10 23:24         ` Jörn Engel
2013-06-11  6:18           ` Hannes Reinecke
2013-06-11 16:35             ` Jörn Engel
2013-06-11 18:57     ` James Bottomley
2013-06-11 20:41       ` Ewan Milne
2013-06-11 20:54         ` James Bottomley
2013-06-12  5:54       ` Hannes Reinecke
2013-06-12  6:34       ` Bart Van Assche
2013-06-12  6:42         ` Hannes Reinecke [this message]
2013-06-10 15:47   ` Jörn Engel
2013-06-10  7:40 ` [PATCH 4/9] virtio_scsi: Enable new EH " Hannes Reinecke
2013-06-12 14:54   ` Paolo Bonzini
2013-06-13  1:58   ` Asias He
2013-06-10  7:40 ` [PATCH 5/9] virtio-scsi: Implement TMF timeout Hannes Reinecke
2013-06-12 14:54   ` Paolo Bonzini
2013-06-13  1:58   ` Asias He
2013-06-10  7:40 ` [PATCH 6/9] libsas: Enable new EH timeout handler Hannes Reinecke
2013-06-10  7:40 ` [PATCH 7/9] mptsas: " Hannes Reinecke
2013-06-10  7:40 ` [PATCH 8/9] mpt2sas: " Hannes Reinecke
2013-06-10 15:31   ` Jörn Engel
2013-06-11  5:41     ` Hannes Reinecke
2013-06-10  7:40 ` [PATCH 9/9] mpt3sas: " Hannes Reinecke
  -- strict thread matches above, loose matches on Subject: below --
2013-07-01 14:24 [PATCHv3 0/9] New EH command " Hannes Reinecke
2013-07-01 14:24 ` [PATCH 3/9] scsi: improved eh " Hannes Reinecke
2013-08-22  8:51   ` Ren Mingxin
2013-08-23 12:27     ` Hannes Reinecke
2013-08-29 13:32 [PATCHv4 0/9] New EH command " Hannes Reinecke
2013-08-29 13:32 ` [PATCH 3/9] scsi: improved eh " Hannes Reinecke
2013-09-02  7:12 [PATCHv5 0/9] New EH command " Hannes Reinecke
2013-09-02  7:12 ` [PATCH 3/9] scsi: improved eh " Hannes Reinecke
2013-09-02 12:45   ` Bart Van Assche
2013-09-02 13:11     ` Hannes Reinecke
2013-09-02 16:38       ` Bart Van Assche
2013-09-03  9:13       ` Bart Van Assche
2013-09-04  7:02         ` Hannes Reinecke

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=51B8184A.6030303@suse.de \
    --to=hare@suse.de \
    --cc=bmr@redhat.com \
    --cc=bvanassche@acm.org \
    --cc=emilne@redhat.com \
    --cc=hch@infradead.org \
    --cc=james.smart@emulex.com \
    --cc=jbottomley@parallels.com \
    --cc=joern@logfs.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=renmx@cn.fujitsu.com \
    --cc=roland@purestorage.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 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.