From: Benjamin Block <bblock@linux.vnet.ibm.com>
To: Hannes Reinecke <hare@suse.de>
Cc: linux-scsi@vger.kernel.org, Mike Christie <michaelc@cs.wisc.edu>,
"James E.J. Bottomley" <JBottomley@odin.com>
Subject: Re: Question about expected behavior of terminate_rport_io() in fc_function_template
Date: Fri, 25 Sep 2015 15:36:41 +0200 [thread overview]
Message-ID: <20150925133641.GA29457@bblock-ThinkPad-W530> (raw)
In-Reply-To: <5603141D.20000@suse.de>
Hej Hannes,
thx for the short explanation.
On 23:05 Wed 23 Sep , Hannes Reinecke wrote:
> On 09/23/2015 07:06 PM, Benjamin Block wrote:
> > Hello,
> >
> > just a short question. If a low-level driver implements the function
> > `terminate_rport_io()` in `struct fc_function_template`, and it gets
> > called after IO failed, is the low-level driver expected to handle this
> > request synchronously or can it just schedule an action that is worked on
> > asynchronously to the call to the function?
> >
> Actually, it doesn't matter, as 'terminate_rport_io()' should cause the
> driver to about outstanding commands. The main idea behind this is that
> the driver clears up any additional state it might have tacked onto the
> command. And calling '->done()', obviously.
>
> Main goal is to have outstanding I/O returned to the upper layers, so
> that things like multipath can redirect outstanding I/O to other paths
> and facilitate quick failover.
>
Yeah, that is what I thought as well, after I read the initial patch
that introduced that function to the template and stack. Makes much more
sense then an implicit rule.
>
> > Trouble is, we are seeing problems with SCSI-Commands being used by the
> > upper layers when we expect them to still be ours, after we got a call to
> > that function and didn't react upon it immediately. They do not contain
> > valid content anymore when they should.
> >
> True; after terminate_rport_io() I/O should have been aborted.
> However, the SCSI layer really shouldn't reuse commands before ->done()
> has been invoked or the command itself has been aborted.
>
> > I've looked into other implementations and it seems there are both
> > version, some LLDs explicitly wait upon completions of requests they
> > schedule and others just schedule work-items and return. That may
> > already be the answer, but I wanted to make sure I am not missing
> > something here. The documentation on it is not really existing, or I
> > missed it.
> >
> As indicated, the driver is expected to call ->done() on outstanding
> commands when terminate_rport_io() is called.
> This smells more like an issue with the driver itself; if I were to
> guess I would think that some aborts are not handled correctly ...
>
> But it's hard to know without details. Do you have some message log or
> something?
>
It may well be that this is a problem in the driver. I am still working
on it, I have logs but those are very messy because the test load
involves LVM volumes with multiple LUNs and multipathing, and I am
trying to reduce it in order to be better able to debug it.
Beste Grüße / Best regards,
- Benjamin Block
--
Linux on z Systems Development / IBM Systems & Technology Group
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp / Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
--
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
prev parent reply other threads:[~2015-09-25 13:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-23 17:06 Question about expected behavior of terminate_rport_io() in fc_function_template Benjamin Block
2015-09-23 21:05 ` Hannes Reinecke
2015-09-25 13:36 ` Benjamin Block [this message]
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=20150925133641.GA29457@bblock-ThinkPad-W530 \
--to=bblock@linux.vnet.ibm.com \
--cc=JBottomley@odin.com \
--cc=hare@suse.de \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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