On Wed, 2014-03-12 at 21:43 +0000, Alex Leung wrote: > On Wed, 2014-03-12 10:40 AM, Nicholas A. Bellinger wrote: > > On Tue, 2014-03-11 at 04:27 +0000, Alex Leung wrote: > > > On Mon, March 10, 2014 6:01 PM, Nicholas A. Bellinger wrote: > > > > On Fri, 2014-03-07 at 02:04 +0000, Alex Leung wrote: > > <SNIP> > > > > > > > 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. > > > > This can be done, but it would be nice if the indication of whether or not > to send a response was made explicit. > > > Otherwise, a se_cmd specific bit to signal ABORT_TASK vs. LUN_RESET > > might be helpful.. > > > > Or maybe a "suppress response" bit? So TASK_ABORTED with > suppress_resp=0 would tell fabric driver to send TASK_ABORTED for the > FCP_CMND and TASK_ABORTED with suppress_resp=1 would indicate > to fabric driver to cleanup internally without sending a response. The > fabric driver would then neither know nor care about what caused the > abort. > Ok, so given that current TAS logic is incorrect as you describe below, is this bit still necessary..? > > > > > 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)." > > > > > > Note: if TAS is zero, "commands shall be terminated by the device service > without any response" > > > > > 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. > > That's not how I understand it. I think the first sentence from your SPC-4 > snippet says it all, as I noted above. Also, according to Table 38 - > SCSI device conditions that abort commands in a SCSI initiator > device (SAM-4): > > ""Yes" indicates that each command that is aborted on an I_T nexus other > than the one that caused the SCSI device condition is completed with > TASK ABORTED status, if the TAS bit is set to one in the Control mode page > (see SPC-4). "No" indicates that no status is returned for aborted > commands." > > I could not find anywhere where an exception is made for the nexus > the LUN Reset was received upon. > Mmm, you are correct. Care to send a (tested) patch that changes core_tmr_handle_tas_abort() to follow the above..? Thanks, --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
