Question about coherency of comand context between ufs and scsi

From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: <linux-scsi@vger.kernel.org>
Cc: "'Can Guo'" <cang@codeaurora.org>,
	"'Bart Van Assche'" <bvanassche@acm.org>,
	"'Avri Altman'" <avri.altman@wdc.com>,
	"'Bean Huo'" <beanhuo@micron.com>,
	"'Jaegeuk Kim'" <jaegeuk@kernel.org>
Subject: Question about coherency of comand context between ufs and scsi
Date: Mon, 14 Jun 2021 18:52:45 +0900	[thread overview]
Message-ID: <000001d76103$06c3cb50$144b61f0$@samsung.com> (raw)
In-Reply-To: CGME20210614095245epcas2p2e8512382423332786f584d5ef1e225d3@epcas2p2.samsung.com

Dear All

I saw one symptom and started wondering on how a command context is synchronized between ufs and scsi.
In the situation where the following log happened, the lrb structure for tag 10 didn't have a command context.
That is, lrbp->cmd was null, so it led to this kernel panic.

lrbp->cmd is set when a command is issued, and cleared when the command is completed.
But what if the command is timed-out and it's completed because its response comes in at the same time?

If scsi added it into its error command list and wakes-up scsi_eh though the command is actually completed, scsi_eh will invoke eh_abort_handler and the symptom will be duplicated, I think

Otherwise, is there anyone who know how to guarantee the coherency?

[78843.058729] [3:  kworker/u16:1:27018] exynos-ufs 13100000.ufs: ufshcd_abort: cmd was completed, but without a notifying intr, tag = 10
[78843.058775] [3:  kworker/u16:1:27018] exynos-ufs 13100000.ufs: ufshcd_abort: Device abort task at tag 10
[78843.058793] [3:  kworker/u16:1:27018] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000160
..
[78843.075421] [3:  kworker/u16:1:27018] pc : scsi_print_command+0x24/0x340
[78843.075436] [3:  kworker/u16:1:27018] lr : ufshcd_abort+0x180/0x674
[78843.075444] [3:  kworker/u16:1:27018] sp : ffffffc038ea3c00
[78843.075453] [3:  kworker/u16:1:27018] x29: ffffffc038ea3c10 x28: 0000000000000400 
[78843.075464] [3:  kworker/u16:1:27018] x27: ffffff8934c0a680 x26: ffffff8931560000 
[78843.075474] [3:  kworker/u16:1:27018] x25: 000000000002000a x24: ffffff88a0dd4910 
[78843.075485] [3:  kworker/u16:1:27018] x23: 0000000000000000 x22: ffffff8930f258f0 
[78843.075495] [3:  kworker/u16:1:27018] x21: ffffff8934c0a080 x20: 000000000000000a 
[78843.075505] [3:  kworker/u16:1:27018] x19: ffffff8931560cf8 x18: ffffffc037557030 
[78843.075516] [3:  kworker/u16:1:27018] x17: 0000000000000000 x16: ffffffc010eeba70 
[78843.075526] [3:  kworker/u16:1:27018] x15: ffffffc01187d88f x14: 2067617420746120 
[78843.075536] [3:  kworker/u16:1:27018] x13: 6b7361742074726f x12: 6261206563697665 
[78843.075546] [3:  kworker/u16:1:27018] x11: 44203a74726f6261 x10: 00000000ffffffff 
[78843.075556] [3:  kworker/u16:1:27018] x9 : 0000000000000090 x8 : ffffff8934c0a620 
[78843.075566] [3:  kworker/u16:1:27018] x7 : 0000000000000000 x6 : ffffffc0102a7d6c 
[78843.075576] [3:  kworker/u16:1:27018] x5 : 0000000000000000 x4 : 0000000000000080 
[78843.075585] [3:  kworker/u16:1:27018] x3 : 0000000000000000 x2 : ffffffc0102a7d80 
[78843.075595] [3:  kworker/u16:1:27018] x1 : ffffffc0102a7d80 x0 : 0000000000000000 
[78843.075606] [3:  kworker/u16:1:27018] Call trace:
[78843.075617] [3:  kworker/u16:1:27018]  scsi_print_command+0x24/0x340
[78843.075627] [3:  kworker/u16:1:27018]  ufshcd_abort+0x180/0x674
[78843.075643] [3:  kworker/u16:1:27018]  scmd_eh_abort_handler+0x80/0x15c
[78843.075660] [3:  kworker/u16:1:27018]  process_one_work+0x290/0x4e4
[78843.075669] [3:  kworker/u16:1:27018]  worker_thread+0x258/0x534
[78843.075681] [3:  kworker/u16:1:27018]  kthread+0x178/0x188
[78843.075696] [3:  kworker/u16:1:27018]  ret_from_fork+0x10/0x18

Thanks.
Kiwoong Kim