All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
	Bart Van Assche <bvanassche@acm.org>,
	SCSI development list <linux-scsi@vger.kernel.org>
Subject: Re: Debugging scsi abort handling ?
Date: Mon, 25 Aug 2014 13:26:07 +0200	[thread overview]
Message-ID: <53FB1D4F.5070606@redhat.com> (raw)
In-Reply-To: <53FB1ACD.1040208@redhat.com>

Hi,

On 08/25/2014 01:15 PM, Paolo Bonzini wrote:
> Il 25/08/2014 12:28, Bart Van Assche ha scritto:
>>
>> From SPC-4: "7.5.8 Control mode page [ ... ] A task aborted status (TAS)
>> bit set to zero specifies that aborted commands shall be terminated by
>> the device server without any response to the application client. A TAS
>> bit set to one specifies that commands aborted by the actions of an I_T
>> nexus other than the I_T nexus on which the command was received shall
>> be completed with TASK ABORTED status (see SAM-5)."
> 
> Note the "aborted by the actions of an I_T nexus other than the I_T
> nexus on which the command was received".
> 
> In practice, this means that TASK ABORTED should only happen if you use
> the CLEAR TASK SET tmf and TST is not set to 001b (i.e. _not_ to "per
> I_T nexus") in the Control mode page.  It should never happen for a pen
> drive.
> 
> Setting TASK ABORTED aside, the important part is that an abort can do
> one of two things:
> 
> - complete the command, and then eh_abort should return after the driver
> has noticed the completion and called the ->scsi_done callback for the
> Scsi_Cmnd*.
> 
> - abort the command, and then the driver should never call the
> ->scsi_done callback for the Scsi_Cmnd*.

Thanks Bart and Paolo, your insights into this are greatly appreciated.

So with uas there are separate usb transaction for cmd, data in, data out
and sense for each tag. At the time of abort, usually one of data in / data
out and a sense usb transaction will be outstanding.

There already is logic in the driver to kill the data in / out transactions
if a sense gets returned (usually with an error) before they are done.

So if I'm reading this correctly, then on a successful abort, the sense
transaction (if not already completed by the target) should be cancelled as
it will never complete, correct ?

I wish the uas spec contained some more details on this, but it is very
vague wrt task management (well it is vague in general, task management just
is extra hard to test).

Regards,

Hans

  reply	other threads:[~2014-08-25 11:26 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 [this message]
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
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=53FB1D4F.5070606@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=bvanassche@acm.org \
    --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.