Christoph, Thanks for reviewing. I¹ll withdraw this patch. Will rework
with new code and submit at a later time.
Regards,
Quinn Tran
On 12/14/15, 2:37 AM, "Christoph Hellwig" <hch@xxxxxxxxxxxxx> wrote:
>On Wed, Dec 09, 2015 at 08:24:57PM +0000, Quinn Tran wrote:
>> >> + if (se_cmd->transport_state & CMD_T_ABORTED) {
>> >> + /* For TCM TAS support n kernel >= 3.15:
>> >> + * This cmd is attempting to respond with "Task Aborted Status".
>> >> + */
>> >> + if (cmd->aborted) {
>> >> + return 0;
>> >> + } else if ((cmd->state == QLA_TGT_STATE_NEED_DATA) &&
>> >> + cmd->cmd_sent_to_fw) {
>> >> + qlt_abort_cmd(cmd);
>> >> + return 0;
>> >> + } else if (cmd->state == QLA_TGT_STATE_PROCESSED) {
>> >> + if (cmd->cmd_sent_to_fw) {
>> >> + qlt_abort_cmd(cmd);
>> >> + return 0;
>> >> + } else { /* about to be free */
>> >> + return 0;
>> >> + }
>> >> + }
>> >> + }
>> >> +
>> >
>> >This is really something that should be explicitly communicated
>> >from the core instead of having to second guess it.
>>
>> QT> The extra protection of the code here is to reduce erroneous error
>> message and interaction error with our firmware. I think communicating
>> back to the core at this stage might add undue complication. It?s best
>>to
>> allow the initiator to re-drive the command at this point.
>
>I agree with that statement, just not how it's done. Having parallel
>command state machines in the driver and core isn't something that's
>maintainable. We need to attack the root cause instead of trying
>to hack around it in drivers.
<<attachment: winmail.dat>>
