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

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

[Bart Van Assche]

ufshcd_queuecommand() may be called two times in a row for a SCSI
command before it is completed. Hence make the following changes:
- In the functions that submit a command, do not check the old value of
  lrbp->cmd nor clear lrbp->cmd in error paths.
- In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.

See also scsi_send_eh_cmnd().

This patch prevents that the following appears if a command times out:

WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
Call trace:
 ufshcd_queuecommand+0x6f8/0x9a8
 scsi_send_eh_cmnd+0x2c0/0x960
 scsi_eh_test_devices+0x100/0x314
 scsi_eh_ready_devs+0xd90/0x114c
 scsi_error_handler+0x2b4/0xb70
 kthread+0x16c/0x1e0

Fixes: 5a0b0cb9bee7 ("[SCSI] ufs: Add support for sending NOP OUT UPIU")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
 drivers/ufs/core/ufshcd.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
index dc4b047db27e..3a7598120d23 100644
--- a/drivers/ufs/core/ufshcd.c
+++ b/drivers/ufs/core/ufshcd.c
@@ -2931,7 +2931,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 		(hba->clk_gating.state != CLKS_ON));
 
 	lrbp = &hba->lrb[tag];
-	WARN_ON(lrbp->cmd);
 	lrbp->cmd = cmd;
 	lrbp->task_tag = tag;
 	lrbp->lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun);
@@ -2947,7 +2946,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
 
 	err = ufshcd_map_sg(hba, lrbp);
 	if (err) {
-		lrbp->cmd = NULL;
 		ufshcd_release(hba);
 		goto out;
 	}
@@ -3166,7 +3164,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
 	down_read(&hba->clk_scaling_lock);
 
 	lrbp = &hba->lrb[tag];
-	WARN_ON(lrbp->cmd);
+	lrbp->cmd = NULL;
 	err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
 	if (unlikely(err))
 		goto out;
@@ -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);
 }
@@ -7023,7 +7020,6 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba,
 	down_read(&hba->clk_scaling_lock);
 
 	lrbp = &hba->lrb[tag];
-	WARN_ON(lrbp->cmd);
 	lrbp->cmd = NULL;
 	lrbp->task_tag = tag;
 	lrbp->lun = 0;
@@ -7195,7 +7191,6 @@ int ufshcd_advanced_rpmb_req_handler(struct ufs_hba *hba, struct utp_upiu_req *r
 	down_read(&hba->clk_scaling_lock);
 
 	lrbp = &hba->lrb[tag];
-	WARN_ON(lrbp->cmd);
 	lrbp->cmd = NULL;
 	lrbp->task_tag = tag;
 	lrbp->lun = UFS_UPIU_RPMB_WLUN;

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

[Adrian Hunter]

On 24/05/23 23:36, Bart Van Assche wrote:
> ufshcd_queuecommand() may be called two times in a row for a SCSI
> command before it is completed. Hence make the following changes:
> - In the functions that submit a command, do not check the old value of
>   lrbp->cmd nor clear lrbp->cmd in error paths.
> - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.
> 
> See also scsi_send_eh_cmnd().
> 
> This patch prevents that the following appears if a command times out:
> 
> WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8
> Call trace:
>  ufshcd_queuecommand+0x6f8/0x9a8
>  scsi_send_eh_cmnd+0x2c0/0x960
>  scsi_eh_test_devices+0x100/0x314
>  scsi_eh_ready_devs+0xd90/0x114c
>  scsi_error_handler+0x2b4/0xb70
>  kthread+0x16c/0x1e0
> 
> Fixes: 5a0b0cb9bee7 ("[SCSI] ufs: Add support for sending NOP OUT UPIU")
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>

Acked-by: Adrian Hunter <adrian.hunter@intel.com>

> ---
>  drivers/ufs/core/ufshcd.c | 7 +------
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c
> index dc4b047db27e..3a7598120d23 100644
> --- a/drivers/ufs/core/ufshcd.c
> +++ b/drivers/ufs/core/ufshcd.c
> @@ -2931,7 +2931,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
>  		(hba->clk_gating.state != CLKS_ON));
>  
>  	lrbp = &hba->lrb[tag];
> -	WARN_ON(lrbp->cmd);
>  	lrbp->cmd = cmd;
>  	lrbp->task_tag = tag;
>  	lrbp->lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun);
> @@ -2947,7 +2946,6 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
>  
>  	err = ufshcd_map_sg(hba, lrbp);
>  	if (err) {
> -		lrbp->cmd = NULL;
>  		ufshcd_release(hba);
>  		goto out;
>  	}
> @@ -3166,7 +3164,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
>  	down_read(&hba->clk_scaling_lock);
>  
>  	lrbp = &hba->lrb[tag];
> -	WARN_ON(lrbp->cmd);
> +	lrbp->cmd = NULL;
>  	err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
>  	if (unlikely(err))
>  		goto out;
> @@ -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);
>  }
> @@ -7023,7 +7020,6 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba *hba,
>  	down_read(&hba->clk_scaling_lock);
>  
>  	lrbp = &hba->lrb[tag];
> -	WARN_ON(lrbp->cmd);
>  	lrbp->cmd = NULL;
>  	lrbp->task_tag = tag;
>  	lrbp->lun = 0;
> @@ -7195,7 +7191,6 @@ int ufshcd_advanced_rpmb_req_handler(struct ufs_hba *hba, struct utp_upiu_req *r
>  	down_read(&hba->clk_scaling_lock);
>  
>  	lrbp = &hba->lrb[tag];
> -	WARN_ON(lrbp->cmd);
>  	lrbp->cmd = NULL;
>  	lrbp->task_tag = tag;
>  	lrbp->lun = UFS_UPIU_RPMB_WLUN;

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

[hoyoung seo]

@@ -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?

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

[Bart Van Assche]

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.

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

[hoyoung seo]

> From: Bart Van Assche <bvanassche@acm.org>
> Sent: Wednesday, June 28, 2023 4:54 AM
> To: hoyoung seo <hy50.seo@samsung.com>
> Cc: Arthur.Simchaev@wdc.com; JBottomley@Parallels.com;
> adrian.hunter@intel.com; athierry@redhat.com; avri.altman@wdc.com;
> beanhuo@micron.com; jaegeuk@kernel.org; jejb@linux.ibm.com; linux-
> scsi@vger.kernel.org; martin.petersen@oracle.com;
> quic_asutoshd@quicinc.com; quic_ziqichen@quicinc.com; santoshsy@gmail.com;
> stanley.chu@mediatek.com; cpgs@samsung.com; sc.suh@samsung.com;
> kwmad.kim@samsung.com; kwangwon.min@samsung.com; sh425.lee@samsung.com
> Subject: Re: [PATCH v3 2/4] scsi: ufs: Fix handling of lrbp->cmd
> 
> 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/f0d923ee1f009f171a55c258d044e814ec0
> > 917ab.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,

Thank you for your kind reply.
Let me take a closer look at the code of the scsi layer

Seo.

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

[hoyoung seo]

>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

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

[hoyoung seo]

>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

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

[Bart Van Assche]

On 2/12/26 2:54 AM, hoyoung seo wrote:
> I have to use kernel-6.18, what should I do in this case?

Please continue the conversation in 
https://b.corp.google.com/issues/480758258 instead of using the 
linux-scsi mailing list.

Bart.