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
