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

Peter Wang (王信友)
2024-06-24T08:54:25Z

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