Q: aborting commands

Q: aborting commands

[Luben Tuikov]

I've been meaning to ask this for some time now:
What is the consensus on the meaning of an aborted command?

Most notably in the SCSI LLP standards, a successfully aborted command
will NOT return status as non-aborted commands would (normally) do.

1. Should successfully aborted commands call scsi_done()?
   (of course with result=DID_ABORT)

>From the point of view of:
Sometimes, a SCSI LLDD can reply with SUCCESS to a command abortion,
BUT the scsi_cmnd structure, including the sg lists may NOT be freed
right away, that is, until later time when the driver can get around
to it to actually yank out/free its own resources, etc. (This is especially
true in queuing models when the command has been submitted to another
entity (HW/SF) which also operates on a similar queueing model.)
Then the SCSI LLDD can notify SCSI core that all its (SCSI core's) memory
is free by calling scsi_done() with DID_ABORT set -- the mid layer
would know what has happened and will reuse/reissue/etc the command.

I do realize that the above IS a two-edged sword in many respects, I just
rambled it just to show another point of view, aside the one taken
by SCSI LLP (transports/interconnects).

2. Can/Should/Must SCSI core assume that a _successfully_ aborted command
   did NOT make it to the medium?

This would be especially useful to UL beasts like journalling FSs, databases,
etc.

I think that if the device supports it, when SUCCESS has been returned, this
should also mean that the command did NOT make it to the medium. (This would
also make it consistent to the semantics of aborting a command.)

Of couse ``medium'' may just mean some cache/buffer on the lowest point
of the physical device (or whatever the manuf. decided to muster up), but
should nevertheless mean that a READ on the media should give consistent
results with aborting the command not making it to the media.

?
-- 
Luben

Re: Q: aborting commands

[Mike Anderson]

Luben Tuikov [luben@splentec.com] wrote:
> I've been meaning to ask this for some time now:
> What is the consensus on the meaning of an aborted command?
> 
> Most notably in the SCSI LLP standards, a successfully aborted command
> will NOT return status as non-aborted commands would (normally) do.
> 
> 1. Should successfully aborted commands call scsi_done()?
>    (of course with result=DID_ABORT)
The new eh on calling eh_abort_handler on a cmd believes that it is the
owner of the command again.

I also noticed an issue in our current error handling in that if call
eh_abort_handler we may want to call eh_device_reset_handler on the
device later in recovery. The issue is that it at least one
implementation by a LLDD this is a either / or case not a progressive
step of error recovery.

> 
> >From the point of view of:
> Sometimes, a SCSI LLDD can reply with SUCCESS to a command abortion,
> BUT the scsi_cmnd structure, including the sg lists may NOT be freed
> right away, that is, until later time when the driver can get around
> to it to actually yank out/free its own resources, etc. (This is especially
> true in queuing models when the command has been submitted to another
> entity (HW/SF) which also operates on a similar queueing model.)
> Then the SCSI LLDD can notify SCSI core that all its (SCSI core's) memory
> is free by calling scsi_done() with DID_ABORT set -- the mid layer
> would know what has happened and will reuse/reissue/etc the command.
> 
> I do realize that the above IS a two-edged sword in many respects, I just
> rambled it just to show another point of view, aside the one taken
> by SCSI LLP (transports/interconnects).
> 
> 2. Can/Should/Must SCSI core assume that a _successfully_ aborted command
>    did NOT make it to the medium?
> 

How could a LLDD know where the error occurred on a timeout. Take FC for
example the problem could be a dropped response IU (with device
completing the cmd) or a class 3 data frame dropped in the middle.

> This would be especially useful to UL beasts like journalling FSs, databases,
> etc.
> 
> I think that if the device supports it, when SUCCESS has been returned, this
> should also mean that the command did NOT make it to the medium. (This would
> also make it consistent to the semantics of aborting a command.)
> 
> Of couse ``medium'' may just mean some cache/buffer on the lowest point
> of the physical device (or whatever the manuf. decided to muster up), but
> should nevertheless mean that a READ on the media should give consistent
> results with aborting the command not making it to the media.

-andmike
--
Michael Anderson
andmike@us.ibm.com

Re: Q: aborting commands

[Luben Tuikov]

Mike Anderson wrote:
> 
> Luben Tuikov [luben@splentec.com] wrote:
> > I've been meaning to ask this for some time now:
> > What is the consensus on the meaning of an aborted command?
> >
> > Most notably in the SCSI LLP standards, a successfully aborted command
> > will NOT return status as non-aborted commands would (normally) do.
> >
> > 1. Should successfully aborted commands call scsi_done()?
> >    (of course with result=DID_ABORT)
>
> The new eh on calling eh_abort_handler on a cmd believes that it is the
> owner of the command again.

Yes, we know. That's why the ability to sleep on eh, else
there's no way out...
 
> I also noticed an issue in our current error handling in that if call
> eh_abort_handler we may want to call eh_device_reset_handler on the
> device later in recovery. The issue is that it at least one
> implementation by a LLDD this is a either / or case not a progressive
> step of error recovery.

I don't understand this.
 
> How could a LLDD know where the error occurred on a timeout. Take FC for
> example the problem could be a dropped response IU (with device
> completing the cmd) or a class 3 data frame dropped in the middle.

Right, in this case it cannot.

Anyway I was just throwing ideas and questions to increase the brainstorm
pool at linux-scsi, nothing more.

-- 
Luben

Re: Q: aborting commands

[Mike Anderson]

Luben Tuikov [luben@splentec.com] wrote:
> Mike Anderson wrote:
> > 
> > Luben Tuikov [luben@splentec.com] wrote:
> > > I've been meaning to ask this for some time now:
> > > What is the consensus on the meaning of an aborted command?
> > >
> > > Most notably in the SCSI LLP standards, a successfully aborted command
> > > will NOT return status as non-aborted commands would (normally) do.
> > >
> > > 1. Should successfully aborted commands call scsi_done()?
> > >    (of course with result=DID_ABORT)
> >
> > The new eh on calling eh_abort_handler on a cmd believes that it is the
> > owner of the command again.
> 
> Yes, we know. That's why the ability to sleep on eh, else
> there's no way out...

Ok so is the question should "all" io complete through scsi_done? 

When I looked at faster recovery of a timed out commands I was trying to
determine if it would be simpler for the abort io to call scsi_done. I
thought it would be because ownership would be cleaner.

It would also be good to start the abort ASAP on a timeout but the
context is wrong if the LLDD needs to sleep.

-andmike
--
Michael Anderson
andmike@us.ibm.com