On Tue, 2014-03-11 at 04:27 +0000, Alex Leung wrote: > Hi Nicholas, > > On Mon, March 10, 2014 6:01 PM, Nicholas A. Bellinger wrote: > > On Fri, 2014-03-07 at 02:04 +0000, Alex Leung wrote: > > > It's not obvious to me why the queue_status() downcall would be made > > > with scsi_status = SAM_STAT_TASK_ABORTED. It would seem to imply that > > > an FCP_RESPONSE with status=40h should be sent on the wire for the > > > associated FCP_CMND. However, since an ABTS was received for the > > > command, no response will be sent for the FCP_CMND itself. Am I > > > reading this correctly? > > > > > > > Yes. It's up to the fabric driver to determine if a ->queue_status being called > > with SAM_STAT_TASK_ABORTED is sent over the wire, or should be > > completed internally. > > > > How can the fabric driver distinguish between this case (Abort Task) that > would never send TASK_ABORTED and, say, LUN RESET, that would send > TASK_ABORTED (provided that the TMR came from a different IT Nexus)? > Not sure I completely understand the case above where ABTS was received, but no response will be sent for the FCP_CMND itself, but I'd assume using the reference tag included in the original ABTS to set a fabric dependent descriptor bit to distinguish this special case. Otherwise, a se_cmd specific bit to signal ABORT_TASK vs. LUN_RESET might be helpful.. > > > core_tmr_handle_tas_abort() has the following 'if' statement before > > > calling transport_send_task_abort(): > > > > > > if ((tmr_nacl && > > > (tmr_nacl == cmd->se_sess->se_node_acl)) || tas) > > > transport_send_task_abort(cmd); > > > > > > It makes sense that if TAS=1, the .queue_status downcall would be made > > > with scsi_status=SAM_STAT_TASK_ABORTED. However, I don't understand > > > the "(tmr_nacl && tmr_nacl == cmd->se_sess->se_node_acl)" part of this > > > statement. > > > > IIRC, this is because TAS only effects nexuses other than the nexus that > > received the LUN_RESET. > > > > > When I configure TAS=0 and send a LUN Reset, the tmr_nacl matches the > > > se_node_acl so the call to transport_send_task_abort() is made > > > regardless of "tas". I would think that if TAS=0, the > > > transport_send_task_abort() call would be skipped. What am I missing? > > > > > > > From SPC-4's description of TAS: > > > > "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-4)." > > > > My understanding wrt to TAS has been that it only effects nexuses other > > than the one that received the LUN_RESET. > > I agree, that's why I would have expected to only send TASK_ABORTED if TAS=1 > and the TMR came from a different IT Nexus. Something like this: > > if ((tmr_nacl && > (tmr_nacl != cmd->se_sess->se_node_acl)) && tas) > transport_send_task_abort(cmd); > My understanding is that TASK_ABORTED is still expected to be sent on the nexus the TMR LUN_RESET was received upon, regardless of the TAS bit setting. This is what the code above reflects. --nab -- 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
