Re: [PATCH v3 2/4] scsi: ufs: Fix handling of lrbp->cmd

["hoyoung seo" <hy50.seo@samsung.com>]

>On 6/26/23 18:26, hoyoung seo wrote:
>> @@ -5408,7 +5406,6 @@ static void ufshcd_release_scsi_cmd(struct ufs_hba *hba,
>>   	struct scsi_cmnd *cmd = lrbp->cmd;
>>   
>>   	scsi_dma_unmap(cmd);
>> -	lrbp->cmd = NULL;	/* Mark the command as completed. */
>>   	ufshcd_release(hba);
>>   	ufshcd_clk_scaling_update_busy(hba);
>>   }
>> 
>> Hi,
>> Is there any reason to delete "lrbp->cmd = NULL"?
>> As far as I know, clear to NULL to indicate that cmd is completed.
>> 
>> When the UFS MCQ mode is activated, check that lrbp->cmd is NULL to check the completion of the command.
>> https://lore.kernel.org/linux-scsi/f0d923ee1f009f171a55c258d044e814ec0917ab.1685396241.git.quic_nguyenb@quicinc.com/
>> 
>> If there is no special reason, why don't you add "lrb->cmd = NULL" again?
>
>The lrbp->cmd = NULL assignment has been removed because if it would be kept
>the SCSI error handler would crash if it reuses a SCSI command. See also the
>scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() callers. The MCQ code should
>still work because it uses blk_mq_request_started() to check whether or not
>a request is still active.
>
>Bart.


Hi, Bart

The problem I asked before was caused by an KASAN error.
I try to work based on kernel-6.18.
When I stability checked, occurred a KASAN error related to UFS was detected.
In below log, UFS driver accessed bad address during operate pending request.
It seems that a problem occurred when accessing the already de-allocated cmd memory.
The cmd memory will de-allocated after IO cmd complete, but lrbp->cmd continues 
to have the address of the released memory.
So occurred below KASAN error.
In fact, the tag at the time of allocation to send cmd is 09, but the tag 
in memory is 90 now.
This means that the memory is released once and then re-allocated by another process.

The situation you mentioned seems to be that the scsi layer uses cmd 
in the error recovery situation, so it should not be made null.
However, in normal situations, scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() 
of the scsi layer do not seem to reuse cmd.
And now the cmd is processed normally and there is a KASAN error while 
checking if there is a pending cmd during UFS re linkup.

I wanted to modify the mainline, but lrbp->cmd was deleted in kernel-6.20.
I have to use kernel-6.18, what should I do in this case?
Please give us your opinion.

================================================================================

BUG: KASAN: invalid-access in ufshcd_mcq_compl_pending_transfer+0x10c/0x21c
Read of size 4 at addr 09ffff881b0a2708 by task kworker/u40:22/3402
Pointer tag: [09], memory tag: [90]

CPU: 5 UID: 0 PID: 3402 Comm: kworker/u40:22 Tainted: G           OE       6.18.1
Workqueue: async async_run_entry_fn
Call trace:
 show_stack+0x18/0x28 (C)
 __dump_stack+0x28/0x3c
 dump_stack_lvl+0x7c/0xa8
 print_address_description+0x7c/0x20c
 print_report+0x70/0x8c
 kasan_report+0xb4/0x114
 __hwasan_load4_noabort+0x88/0x98
 ufshcd_mcq_compl_pending_transfer+0x10c/0x21c
 ufshcd_host_reset_and_restore+0x26c/0x2c4
 ufshcd_reset_and_restore+0xcc/0x554
 __ufshcd_wl_resume+0x100/0x510
 ufshcd_wl_resume+0x70/0x284
 scsi_bus_resume+0x70/0xb4
 dpm_run_callback+0xa0/0x358
 device_resume+0x2b8/0x3b4
 async_resume+0x24/0x3c
 async_run_entry_fn+0x68/0x210
 process_one_work+0x3fc/0x954
 worker_thread+0x3e4/0x5b0
 kthread+0x388/0x3f0
 ret_from_fork+0x10/0x20

The buggy address belongs to the object at ffffff881b0a2600
 which belongs to the cache kmalloc-512 of size 512
The buggy address is located 264 bytes inside of
 416-byte region [ffffff881b0a2600, ffffff881b0a27a0)

The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89b0a0
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:e4ffff881b0a4a01
flags: 0x4000000000000040(head|zone=1|kasantag=0x0)
page_type: f5(slab)
raw: 4000000000000040 06ffff8800008ac0 fffffffee15a3810 fffffffee83bd810
raw: 0000000000000000 0000000000150015 00000000f5000000 e4ffff881b0a4a01
head: 4000000000000040 06ffff8800008ac0 fffffffee15a3810 fffffffee83bd810
head: 0000000000000000 0000000000150015 00000000f5000000 e4ffff881b0a4a01
head: 4000000000000003 fffffffee06c2801 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffffff881b0a2500: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
 ffffff881b0a2600: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
>ffffff881b0a2700: 90 90 90 90 90 90 90 90 90 90 fe fe fe fe fe fe

                   ^
 ffffff881b0a2800: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
 ffffff881b0a2900: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
==================================================================
Kernel panic - not syncing: KASAN: panic_on_warn set ...

Thanks
SEO