On Mon, 2024-06-24 at 11:12 -0700, Bart Van Assche wrote: > > External email : Please do not click links or open attachments until > you have verified the sender or the content. > On 6/24/24 1:54 AM, Peter Wang (王信友) wrote: > > Your backtrace is Single doorbell mode. But I am curious that > > how could it happen if complete a cmd twice and get null pointer > > next time queuecommand? could you describe the exactly flow? > > SCSI commands are completed only once. See also the code in the SCSI > core that sets the SCMD_STATE_COMPLETE bit: > > $ git grep -nH 'test_and_set_bit(SCMD_STATE_COMPLETE' > drivers/scsi/scsi_error.c:362:if > (test_and_set_bit(SCMD_STATE_COMPLETE, > &scmd->state)) > drivers/scsi/scsi_lib.c:1716:if > (unlikely(test_and_set_bit(SCMD_STATE_COMPLETE, &cmd->state))) > > In other words, either the regular completion code is executed by > scsi_done_internal() or error handling is initiated by > scsi_timeout(). > Only one of the two happens. > > The only exception is that .eh_timed_out() may be called concurrently > with the regular completion handler. Hence this patch for > ufshcd_eh_timed_out(). > > Bart. Hi Bart, I still confused. When eh_timed_out() called concurrently with the regular completion handler. Both process use test_and_set_bit(SCMD_STATE_COMPLETE, &cmd->state) to set SCMD_STATE_COMPLETE flag. test_and_set_bit should be atomice operation? and only one can set this bit than run forward? BTW, I still don't understand if both eh_timed_out and regular completion handler set SCMD_STATE_COMPLETE, what is the relation between SCMD_STATE_COMPLETE and ufshcd_queuecommand null pointer? Thanks. Peter
