On 10/14/2015 05:56 PM, Quinn Tran wrote:
QT> there are 2 places a command can reside: back end or front end.
This patch intercepts the command midway after the command has completed
from the backend (target_complete_cmd-> transport_handle_abort).
IF the command is stuck at back end, then this TMR thread makes no
obvious call to abort the command because there is not an official API
call to the backend. It seems like the target_stop_cmd() call is
reserved for the backend folks to add their specific call to abort (I’m
guessing based on the CMD_T_BUSY flag).
IF the command is stuck at the front end, this patch removed the trigger
to cleanup the command or shortens command’s life.
Behind core_tmr_handle_tas_abort() is the
“cmd->se_tfo->aborted_task(cmd)” call that is of interest that trigger
the cleanup.
I think we should preserve the old semantic where we still keep the
aborted_task() call in this loop? Otherwise, half of the commands that
made to Fabric drivers don’t get the trigger to cleanup.
The kref_get_unless_zero() from above should prevent any race condition
or command premature free.
Hello Quinn,
Aborting a SCSI command that is being handled by the back-end driver
would be an interesting feature. I think Hannes asked for that feature
during the most recent LSF/MM workshop. However, as far as I know none
of the existing LIO back-end drivers nor any of the SCST back-end
drivers supports this feature today.
Regarding the aborted_task() call: had you noticed that that call has
been moved to a new function, namely transport_handle_abort() ? Are you
aware that the aborted_task() function must only be called after the
back-end driver has finished processing a command ? My purpose was to
keep the invocation of the aborted_task() callback function after the
back-end driver has finished with its processing and before the target
core cleans up a command. If you think that I missed a place where that
callback function should be invoked please let me know.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
