linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: linux-scsi@vger.kernel.org
Cc: Hannes Reinecke <hare@suse.de>
Subject: EH method APIs
Date: Fri, 4 Apr 2014 00:04:08 -0700	[thread overview]
Message-ID: <20140404070408.GA30326@infradead.org> (raw)

One think I noticed when doing the SCSI MQ work is that our EH method
signature are starting to really get into the way by passing a scsi_cmnd
as the only argument.  While we'll obviously need the command we want
to abort for eh_abort the resets aren't command specific at all and
passing the command doesn't seem too helpful in general.

There's two specific reasons why it's getting in it's way:

 - With the cmd_size field in the host template we can now allocate
   driver specific data as part of the scsi_cmnd, but we'll usually
   still need driver specific data to do the actual error handling.
   The virtio_scsi driver conversion I posted is a good example of that.
 - The scsi_reset_provider situation is getting worse: this fakes up
   a request on stack, then allocates a scsi_command which doesn't get
   fully set up and points to it and calls the eh_reset* methods on it.
   For now we can keep doing that even with blk-mq, but if we eventually
   want to remove the old code we need a way to fake up the request/cmnd
   combo.  Even until then drivers get a command that subtly different
   from normal ones from scsi_reset_provider in the old code case, and
   even more subtly different for scsi-mq.

I wonder if we should start adding new methods that pass a tmf context
soon.  I think Hannes was looking into EH methods that match the SAM
error handling concepts better anyway, so this might be a good synergy.

             reply	other threads:[~2014-04-04  7:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-04  7:04 Christoph Hellwig [this message]
2014-04-04  7:17 ` EH method APIs Hannes Reinecke
2014-04-04  7:24   ` Christoph Hellwig
2014-04-04  7:36     ` Hannes Reinecke
2014-04-04  7:42       ` Christoph Hellwig

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=20140404070408.GA30326@infradead.org \
    --to=hch@infradead.org \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.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 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).