Hi Mike

Thanks very much for your analysis.

diff --git a/drivers/target/target_core_user.c 
b/drivers/target/target_core_user.c
index 2e33100..6396581 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -684,7 +684,6 @@ static int tcmu_check_expired_cmd(int id, void *p, void 
*data)
set_bit(TCMU_CMD_BIT_EXPIRED, &cmd->flags);
        target_complete_cmd(cmd->se_cmd, SAM_STAT_CHECK_CONDITION);
-       cmd->se_cmd = NULL;
How did tcmu_handle_completion get to a point it was accessing the
se_cmd if the TCMU_CMD_BIT_EXPIRED bit was set?
Were memory accesses out
of order?
No, even using the -O3, becuase has there memory dependency ?

CPU1 set the TCMU_CMD_BIT_EXPIRED bit then cleared
cmd->se_cmd, but CPU2 copied cmd->se_cmd to se_cmd and saw it was NULL
but did not yet see the TCMU_CMD_BIT_EXPIRED bit set?

Because the debug rpms for my kernel version were lost, and the crash
tools couldn't be used to have a more accurate analysis.

It looks like, if you do the above patch, the above function will call
target_complete_cmd and tcmu_handle_completion will call it again, so we
will have a double free issue.
Maybe the best resolution is to move tcmu_handle_completion() between
spin_lock(&udev->commands_lock) and spin_unlock(&udev->commands_lock)?

Thanks.

BRs
Xiubo Li


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to