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
