Re: [PATCH 8/8] scsi: ufs: Check for completion from the timeout handler

["Peter Wang (王信友)" <peter.wang@mediatek.com>]

On Fri, 2024-06-21 at 10:23 -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/20/24 11:54 PM, Peter Wang (王信友) wrote:
> >    Unable to handle kernel NULL pointer dereference at virtual
> address
> > 0000000000000194
> >    pc : [0xffffffddd7a79bf8] blk_mq_unique_tag+0x8/0x14
> >    lr : [0xffffffddd6155b84] ufshcd_mcq_req_to_hwq+0x1c/0x40
> > [ufs_mediatek_mod_ise]
> >     do_mem_abort+0x58/0x118
> >     el1_abort+0x3c/0x5c
> >     el1h_64_sync_handler+0x54/0x90
> >     el1h_64_sync+0x68/0x6c
> >     blk_mq_unique_tag+0x8/0x14
> >     ufshcd_err_handler+0xae4/0xfa8 [ufs_mediatek_mod_ise]
> >     process_one_work+0x208/0x4fc
> >     worker_thread+0x228/0x438
> >     kthread+0x104/0x1d4
> >     ret_from_fork+0x10/0x20
> 
> Hi Peter,
> 
> The above backtrace can only occur with MCQ enabled. The backtrace I
> posted was triggered on a system with a UFSHCI 3.0 controller (no
> MCQ).
> So I think that the backtraces have different root causes and hence
> that
> different patches are required to fix both crashes.
> 
> Thanks,
> 
> Bart.
> 

Hi Bart,

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?

More, because ufshcd_eh_timed_out could run in MCQ mode.
So, this patch will get null pointer when racing happen in MCQ mode.

Thanks
Peter