Question about aborting commands

Question about aborting commands

[scameron]

If a command is aborted by an abort error handler function in
a LLD, and the aborted command comes back from the HBA with a
status that indicates it was aborted, what status (in cmd->result,
and/or sense data?) is the mid layer expecting in such a case?

Just wondering, because in playing around with adding an abort
handler to the hpsa driver for controllers which are able to do
aborts, I can cause commands to be aborted, and I copy the
sense data back to the mid layer, and give it a
cmd->result = DID_ABORT << 16.  

That is, it's hitting this case in hpsa.c: complete_scsi_command()

        case CMD_ABORTED:
                cmd->result = DID_ABORT << 16;
                dev_warn(&h->pdev->dev, "cmd %s was aborted with "
                                "status 0x%x\n", fmtcmd, ei->ScsiStatus);

it does not seem to be hitting this case below, (same function).
That is, it's not getting a target status/check condition/aborted command.)

                        if (sense_key == ABORTED_COMMAND) {
                                /* Aborted command is retryable */
                                dev_warn(&h->pdev->dev, "cmd %s "
                                        "has check condition: aborted command: "
                                        "ASC: 0x%x, ASCQ: 0x%x\n",
                                        fmtcmd, asc, ascq);
                                cmd->result = DID_SOFT_ERROR << 16;
                                break;
                        }

And, I have a dd running which
I think I have aborted one of the commands that was reading data
for that dd, and yet the dd proceeds happily along, oblivious.
This makes me think I'm not doing the right thing to alert the
mid layer that the command got aborted -- or else the midlayer is
retrying the command somehow? I didn't see how this would happen,
but maybe I missed it.

Or, maybe I should be reporting the CMD_ABORTED case back as

	cmd->result = DID_SOFT_ERROR << 16;

-- steve

Re: Question about aborting commands

[Peter Chang]

Le 25 mai 2011 06:50,  <scameron@beardog.cce.hp.com> a écrit :
> Or, maybe I should be reporting the CMD_ABORTED case back as
>
>        cmd->result = DID_SOFT_ERROR << 16;

look at scsi_error.c:scsi_decide_disposition(). DID_SOFT_ERROR
triggers retry handling while DID_ABORT does not (at least in the tree
that i'm looking at).

\p
--
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

Re: Question about aborting commands

[scameron]

> Le 25 mai 2011 06:50,  <scameron@beardog.cce.hp.com> a écrit :
> > Or, maybe I should be reporting the CMD_ABORTED case back as
> >
> >        cmd->result = DID_SOFT_ERROR << 16;
> 
> look at scsi_error.c:scsi_decide_disposition(). DID_SOFT_ERROR
> triggers retry handling while DID_ABORT does not (at least in the tree
> that i'm looking at).
> 

Yes this is what I was looking at, and part of what is confusing me.
This makes me think that DID_ABORT is the wrong thing to do, because 
it would seem that there is no retry, and yet, dd does not complain
that one of the reads initiated on it's behalf has been aborted.
Does that mean it copied bogus data (uninitialized memory)?  Not sure,
but if so, that would be bad. (Easy enough to test this case.)

So this makes me wonder what DID_ABORT is intended to be used for,
and that I am using in a wrong way.

DID_SOFT_ERROR seems as you say like it will cause the command to be retried.
However, if a command is aborted by the error handler at the mid-layer's
request, is it up to the driver to tell the mid layer to retry the
command?  Seems like it would be up to the midlayer to know if it wanted
to retry the command or not..

Then there seems to be some sense key that means the command is aborted
(wondering if the firmware ought to be returning those instead of some
vendor specific way of reporting aborted commands as it seems to do now.)

Maybe the mid-layer is expecting a particular sense key back from a
command which it has aborted, and maybe I'm not setting that?

-- steve

--
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

Re: Question about aborting commands

[Mike Christie]

On 05/25/2011 03:24 PM, scameron@beardog.cce.hp.com wrote:
>> Le 25 mai 2011 06:50,  <scameron@beardog.cce.hp.com> a écrit :
>>> Or, maybe I should be reporting the CMD_ABORTED case back as
>>>
>>>        cmd->result = DID_SOFT_ERROR << 16;
>>
>> look at scsi_error.c:scsi_decide_disposition(). DID_SOFT_ERROR
>> triggers retry handling while DID_ABORT does not (at least in the tree
>> that i'm looking at).
>>
> 
> Yes this is what I was looking at, and part of what is confusing me.
> This makes me think that DID_ABORT is the wrong thing to do, because 
> it would seem that there is no retry, and yet, dd does not complain
> that one of the reads initiated on it's behalf has been aborted.
> Does that mean it copied bogus data (uninitialized memory)?  Not sure,
> but if so, that would be bad. (Easy enough to test this case.)


scsi_decide_disposition is not used in the abort path. In the abort path
commands go through scsi_eh_flush_done_q. In there you can see some
basic handling. We check if we can failfast the cmd (scsi_noretry_cmd)
and if there are enough retries. If it is not fastfailbale and there are
enough retries we retry the IO by calling scsi_queue_insert.

If there are not enough retries or we want to fastfail it then
scsi_finish_command is called like is done in the normal completion path
from (scsi_softirq_done -> scsi_decide_disposition -> (look at return
value) -> scsi_finish_command.

From scsi_finish_command the cmd is then handled like in the normal path
where something like the ULD done function is called then
scsi_io_completion is.

So as you can see from scsi_eh_flush_done_q, the scsi layer does not
really look at what you return and do anything with it. There is just
the basic check for if the IO is fastfailable. When I added that code,
it looked like most drivers returned a wide range of values and in some
cases did not return anything (if a driver does not set anything for the
result then there is that check in scsi_eh_flush_done_q that sets the
DRIVER_TIMEOUT bit).

I do not know what the policy is. I have been converting drivers to
return something useful when they want to control if IO is fastfailed in
this path.
--
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