From: Hans de Goede <hdegoede@redhat.com>
To: Hannes Reinecke <hare@suse.de>, Finn Thain <fthain@telegraphics.com.au>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Bart Van Assche <bvanassche@acm.org>,
SCSI development list <linux-scsi@vger.kernel.org>,
Robert Elliot <elliot@hp.com>
Subject: Re: Debugging scsi abort handling ?
Date: Fri, 29 Aug 2014 12:39:45 +0200 [thread overview]
Message-ID: <54005871.4040300@redhat.com> (raw)
In-Reply-To: <54005642.8050805@suse.de>
Hi,
On 08/29/2014 12:30 PM, Hannes Reinecke wrote:
> On 08/29/2014 12:14 PM, Finn Thain wrote:
>>
>> On Fri, 29 Aug 2014, Hannes Reinecke wrote:
>>
>>> On 08/29/2014 06:39 AM, Finn Thain wrote:
>>>>
>>>> On Thu, 28 Aug 2014, Hannes Reinecke wrote:
>>>>
>>>>> What might happen, though, that the command is already dead and gone
>>>>> by the time you're calling ->scsi_done() (if you call it after
>>>>> eh_abort). So there might not _be_ a command upon which you can call
>>>>> ->scsi_done() to start with.
>>>>>
>>>>> Hence any LLDD need to clear up any internal references after a call
>>>>> to eh_XXX to ensure it doesn't call ->scsi_done() an in invalid
>>>>> command.
>>>>>
>>>>> So even if the LLDD returns 'FAILED' upon a call to eh_XXX it
>>>>> _still_ needs to clear up the internal reference.
>>>>
>>>> This is a question that has been bothering me too. If the host's
>>>> eh_abort_cmd() method returns FAILED, it seems the mid-layer is liable
>>>> to re-issue the same command to the LLD (?)
>>>>
>>> No.
>>> FAILED for any eh_abort_cmd() means that the TMF hasn't been sent.
>>
>> Makes sense, though it appears to contradict this advice about returning
>> SUCCESS in some situations:
>> http://marc.info/?l=linux-scsi&m=140923498632496&w=2
>>
> Well, if the LLDD detects an invalid command (ie if it cannot find any internal command matching the midlayer command) that's an automatic success, obviously.
>
> So we should rephrase things to:
>
> - The eh_XXX callback shall return 'SUCCESS' if the respective
> TMF (or equvalent) could be initiated or if the matching command
> reference has already been completed by the LLDD. Otherwise
> the eh_XXX callback shall return 'FAILED'.
Your talking about "could be initiated", so that means that at this
point the abort does not yet have to be completed, do I get that
right? What should the LLDD then do when the abort finishes,
call eh_scsi_done on the cmnd ?
What about the abort never finishing (timeout), does the mid layer
track this, or should the LLDD do that?
Regards,
Hans
next prev parent reply other threads:[~2014-08-29 10:39 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 14:52 Debugging scsi abort handling ? Hans de Goede
2014-08-23 15:42 ` Douglas Gilbert
2014-08-24 8:39 ` Hans de Goede
2014-08-23 21:05 ` James Bottomley
2014-08-24 8:46 ` Hans de Goede
2014-08-24 21:12 ` Christoph Hellwig
2014-08-25 7:20 ` Paolo Bonzini
2014-08-25 8:47 ` Hans de Goede
2014-08-25 10:28 ` Bart Van Assche
2014-08-25 11:15 ` Paolo Bonzini
2014-08-25 11:26 ` Hans de Goede
2014-08-25 11:39 ` Paolo Bonzini
2014-08-25 15:41 ` James Bottomley
2014-08-26 8:13 ` Hans de Goede
2014-08-26 18:34 ` James Bottomley
2014-08-26 19:19 ` Hans de Goede
2014-08-28 12:10 ` Hannes Reinecke
2014-08-28 12:24 ` Hans de Goede
2014-08-28 12:04 ` Hannes Reinecke
2014-08-28 12:17 ` Paolo Bonzini
2014-08-28 12:26 ` Hans de Goede
2014-08-28 12:33 ` Paolo Bonzini
2014-08-28 12:37 ` Hans de Goede
2014-08-28 14:08 ` James Bottomley
2014-08-28 14:17 ` Hannes Reinecke
2014-08-28 14:56 ` Paolo Bonzini
2014-08-28 15:13 ` Hannes Reinecke
2014-08-28 15:50 ` Elliott, Robert (Server Storage)
2014-08-28 15:54 ` Paolo Bonzini
2014-08-28 15:56 ` Christoph Hellwig
2014-08-29 4:39 ` Finn Thain
2014-08-29 6:08 ` Hannes Reinecke
2014-08-29 7:48 ` Paolo Bonzini
2014-08-29 10:14 ` Finn Thain
2014-08-29 10:30 ` Hannes Reinecke
2014-08-29 10:39 ` Hans de Goede [this message]
2014-08-29 10:49 ` Hannes Reinecke
2014-08-28 12:21 ` Hans de Goede
2014-08-28 14:09 ` James Bottomley
2014-08-29 4:37 ` Finn Thain
2014-08-29 4:52 ` Elliott, Robert (Server Storage)
2014-08-28 12:31 ` Martin Peschke
2014-08-28 14:22 ` 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=54005871.4040300@redhat.com \
--to=hdegoede@redhat.com \
--cc=bvanassche@acm.org \
--cc=elliot@hp.com \
--cc=fthain@telegraphics.com.au \
--cc=hare@suse.de \
--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 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.