On Fri, 23 Oct 2026 17:01:01 +0900, Daejun Park wrote: > Which host path is in-transition meant to reach? In Linux, QUERY TASK > is sent only by ufshcd_try_to_abort_task(). When it runs from > ufshcd_abort() after a SCSI timeout, scsi_timeout() has already set > SCMD_STATE_COMPLETE (drivers/scsi/scsi_error.c:391), so scsi_done() > drops the completion posted here (drivers/scsi/scsi_lib.c:1772). The > request stays MQ_RQ_IN_FLIGHT, ufshcd_cmd_inflight() stays true, and > the loop returns -EBUSY after 100 "not pending" replies > (drivers/ufs/core/ufshcd.c:7993-8026). The "completed" branch is never > taken, and recovery ends in a host reset, as with abort-failed. I got > this with O_DIRECT writes on mainline 7.3-rc7 (MCQ and legacy) and on > ACK android17-6.18 (MCQ). > > If the target is a path where the host does take this completion, for > example ufshcd_abort_all() from the error handler, the host would see a > WRITE succeed although no data reached the LU.
You are right that the completion posted after scsi_timeout() is dropped and recovery ends in a host reset. The mode does not target a specific host branch. It reproduces a device that finishes a command at the moment the host times it out and aborts it, which is hard to hit on real hardware. That window already exposed a few races in the Linux error handler, such as a double completion. Whether the host should take that completion is a Linux policy. The device model should not decide it. v3 no longer fakes the completion. When QUERY TASK arrives, the held command really runs and its data reaches the LU. QUERY TASK then reports the actual task status. > This repeats the generic ABORT TASK code in ufs_process_tmr(). The held > request is in UFS_REQUEST_RUNNING, so ufs_find_req_by_tag() finds it, > and releasing the hold and returning false gives the same result. The > same is true for the QUERY TASK SUCCEEDED branch above. With both > changed (17 deletions, 4 insertions), the UFS qtests pass 29/29. Done. Thanks, Stanley
