Re: Question about coherency of comand context between ufs and scsi

[Can Guo <cang@codeaurora.org>]

On 2021-06-15 16:07, Can Guo wrote:
> On 2021-06-15 15:56, Kiwoong Kim wrote:
>>> If scsi added it into its error command list and wakes-up scsi_eh
>>> though the command is actually completed, scsi_eh will invoke
>>> eh_abort_handler and the symptom will be duplicated, I think
>>> 
>>> Otherwise, is there anyone who know how to guarantee the coherency?
>> 

scsi_times_out() guarantees that -

300 		/*
301 		 * Set the command to complete first in order to prevent a real
302 		 * completion from releasing the command while error handling
303 		 * is using it. If the command was already completed, then the
304 		 * lower level driver beat the timeout handler, and it is safe
305 		 * to return without escalating error recovery.
306 		 *
307 		 * If timeout handling lost the race to a real completion, the
308 		 * block layer may ignore that due to a fake timeout injection,
309 		 * so return RESET_TIMER to allow error handling another shot
310 		 * at this command.
311 		 */
312 		if (test_and_set_bit(SCMD_STATE_COMPLETE, &scmd->state))
313 			return BLK_EH_RESET_TIMER;

Please read above comments.

Can Guo.

>>> In 5.13 kernel, it is scsi_print_command(cmd) in ufshcd_abort(), 
>>> while in
>>> 5.12 and earlier kernel, it is scsi_print_command(hba->lrb[tag].cmd).
>>> Which kernel are you using here?
>>> 
>>> Thanks,
>>> Can Guo.
>> 
>> Thank you for your information. I'm seeing 5.4.
>> Yes, for null pointer, you're right.
>> Then, what do you think?
>> In the situation I told, is there still the possibility that I 
>> suggested?
> 
> You can make the code change to that line in your project same as 5.13.
> 
> Thanks,
> 
> Can Guo.
> 
>> 
>> Thanks.
>> Kiwoong Kim