On 3/13/2014 12:04 PM, Nicholas A. Bellinger wrote: > 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> >> 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..? > I believe so. More below... <SNIP> > Care to send a (tested) patch that changes core_tmr_handle_tas_abort() > to follow the above..? The problem with simply changing the statement to only call transport_check_aborted_status() when TAS=1 and IT Nexus (cmd) != IT Nexus (tmr) is, if TAS=0 (or IT Nexus matches), there won't be any notification to the fabric driver that the given se_cmd has been aborted. What we could do is call core_tmr_handle_tas_abort (probably rename it) no matter what and set a "suppress_response" bit in the se_cmd which is set based on TAS and IT Nexus matching/not matching. That way, the fabric driver will get the notification that the command has been aborted (se_cmd.transport_state & CMD_T_ABORTED) and whether or not a TASK_ABORTED status needs to be sent (!(se_cmd.se_cmd_flags & SCF_SUPPRESS_RESP)). Should I put go down this route and put a patch together? Thanks, Alex -- 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
