mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kiwoong Kim <kwmad.kim@samsung.com>
To: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	alim.akhtar@samsung.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, bvanassche@acm.org,
	kwangwon.min@samsung.com, hy50.seo@samsung.com, cpgs@samsung.com,
	h10.kim@samsung.com
Cc: stable@vger.kernel.org, stanleyjhu@google.com,
	Kiwoong Kim <kwmad.kim@samsung.com>
Subject: [PATCH v7 2/2] scsi: ufs: mcq: poll OCS after sq cleanup for device management commands
Date: Fri,  6 Nov 2026 13:12:47 +0900	[thread overview]
Message-ID: <a1af44cd90dca0dd8a9a06d09a254a4e7e0861b2.1793938245.git.kwmad.kim@samsung.com> (raw)
In-Reply-To: <cover.1793938245.git.kwmad.kim@samsung.com>

Extend ufshcd_mcq_sq_cleanup() to poll the OCS field in the UTRD of a
device management command after a successful SQ_CUS poll. UFSHCI does not
specify the order between the OCS update and the SQ_CUS update, so OCS may
still be stale when cleanup returns. Without this poll, a late response to
a timed-out query can arrive while a retry is already in flight, leaving
the host controller with two query contexts and raising IS.UTPES.

Here is the timeline of an actual case I found with kernel 6.18:

1. The driver sent a query but the device didn't respond to it
   for a long time.

[ 7384.156142] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_mcq_sq_cleanup, hwq 0: cleanup return code (RTC) 0
[ 7384.156154] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = -11

2. So after the query timed out, the driver did SQ cleanup. Then
   the host controller updated the CQ tail and raised IS.CQES.
   Unfortunately, complete() was called by the driver's ISR afterward.

3. The driver started to retry the query. In the meantime,
   it set OCS to 0xF. Then the driver didn't wait for completion due to
   the previous complete() call, and just checked OCS.

[ 7384.156163] [4:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = 15

4. The driver retried the query again, but the device didn't
   return anything, so the query also timed out.

[ 7385.660108] [3:  kworker/u40:5:10671] exynos-ufs 38300000.ufs: ufshcd_query_flag: Sending flag query for idn 14 failed, err = -11

5. A few seconds later, the device returned the response of
   the first query, but since the host controller was holding
   two query contexts and couldn't handle it, it raised IS.UTPES.

The same problem exists in the current code. If the query times out, the
SCSI error handler calls ufshcd_abort() -> ufshcd_mcq_abort() ->
ufshcd_mcq_sq_cleanup(), the request is finished, and the retry reuses the
same reserved tag, struct scsi_cmnd and devman UCD. A late CQE for the
first query then maps to the same tag and completes the retry by calling
scsi_done() too early. The retry then returns the OCS of the first query
and, if that OCS is OCS_SUCCESS, its response as well. Hence
ufshcd_mcq_sq_cleanup() must not return until the CQE of the cleaned-up
request has been processed.

The poll is limited to device management commands because
ufshcd_compl_one_cqe() copies the OCS from the CQE into the UTRD only for
them. For SCSI commands, the OCS in the UTRD stays
OCS_INVALID_COMMAND_STATUS, so polling it would always time out.

The poll waits until OCS is no longer OCS_INVALID_COMMAND_STATUS or
MCQ_POLL_US elapses. -ETIMEDOUT is returned only if OCS is still
OCS_INVALID_COMMAND_STATUS after the poll. Any other value, such as
OCS_ABORTED reported by the host controller for the cleaned-up request,
means the cleanup has completed.
The UFSHCI specification says "The host controller shall free up
any resources associated to the nexus, and shall post
a Completion Queue entry with OCS = ABORTED if clean up successful."

Each poll iteration reaps the CQ with ufshcd_mcq_poll_cqe_lock() before
reading the OCS, as ufshcd_clear_lu_cmds() does after ufshcd_clear_cmd().
This removes the dependency on interrupt delivery. Otherwise the OCS is
only updated once the interrupt handler processes the CQE, and a delayed
or lost interrupt would make the poll time out and escalate to a host
reset although the request has already been cleaned up.

The OCS is still read under hwq->cq_lock because the interrupt handler may
reap the CQE between the reap and the read. ufshcd_compl_one_cqe() updates
the OCS under that lock before it sets cmd->result and calls scsi_done().
Without the lock, cleanup could observe the new OCS and return while the
completion is still running. The abort could then finish the command and
a retry could reuse the same reserved request before the pending
scsi_done() call, which would then complete the retry prematurely.

Fixes: 8d7290348992 ("scsi: ufs: mcq: Add supporting functions for MCQ abort")
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
---
 drivers/ufs/core/ufs-mcq.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
index 8106d55f4041..889f0b78034c 100644
--- a/drivers/ufs/core/ufs-mcq.c
+++ b/drivers/ufs/core/ufs-mcq.c
@@ -550,6 +550,23 @@ static int ufshcd_mcq_sq_start(struct ufs_hba *hba, struct ufs_hw_queue *hwq)
 	return err;
 }
 
+/*
+ * Reap the CQ directly so that progress does not depend on interrupt
+ * delivery. ufshcd_compl_one_cqe() updates the OCS under cq_lock before
+ * calling scsi_done(). Holding cq_lock while reading the OCS makes sure that
+ * the completion has finished once the updated OCS is observed, even if the
+ * CQE was reaped by the interrupt handler.
+ */
+static enum utp_ocs ufshcd_mcq_poll_ocs(struct ufs_hba *hba,
+					struct ufs_hw_queue *hwq,
+					struct ufshcd_lrb *lrbp)
+{
+	ufshcd_mcq_poll_cqe_lock(hba, hwq);
+
+	guard(spinlock_irqsave)(&hwq->cq_lock);
+	return READ_ONCE(lrbp->utr_descriptor_ptr->header.ocs);
+}
+
 /**
  * ufshcd_mcq_sq_cleanup - Clean up submission queue resources
  * associated with the pending command.
@@ -609,6 +626,23 @@ int ufshcd_mcq_sq_cleanup(struct ufs_hba *hba, int task_tag)
 			 __func__, id,
 			 FIELD_GET(SQ_ICU_ERR_CODE_MASK, readl(reg)));
 
+	/*
+	 * For device management commands, there is no order guaranteed between
+	 * OCS update and CUS update, which is why we need to wait here. SCSI
+	 * commands are excluded because the OCS in their UTRD is not updated
+	 * from the CQE.
+	 */
+	if (!err && blk_mq_is_reserved_rq(rq)) {
+		enum utp_ocs ocs;
+
+		err = read_poll_timeout(ufshcd_mcq_poll_ocs, ocs,
+					ocs != OCS_INVALID_COMMAND_STATUS, 20,
+					MCQ_POLL_US, false, hba, hwq, lrbp);
+		if (err)
+			dev_err(hba->dev, "%s: OCS not updated. hwq=%d, tag=%d err=%d\n",
+				__func__, id, task_tag, err);
+	}
+
 	if (ufshcd_mcq_sq_start(hba, hwq))
 		err = -ETIMEDOUT;
 
-- 
2.43.0


  parent reply	other threads:[~2026-11-06  4:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20261106041300epcas2p4a1028afe27a91c8d6167d422c8be1fb1@epcas2p4.samsung.com>
2026-11-06  4:12 ` [PATCH v7 0/2] scsi: ufs: fix the abort path of device management commands in MCQ mode Kiwoong Kim
     [not found]   ` <CGME20261106041301epcas2p39724ab936d6c1cb3b5b899f674623975@epcas2p3.samsung.com>
2026-11-06  4:12     ` [PATCH v7 1/2] scsi: ufs: core: skip ABORT TASK for device management commands Kiwoong Kim
2026-11-06  4:53       ` Bart Van Assche
     [not found]   ` <CGME20261106041303epcas2p19b0c317d409503c833ae125ba91fe053@epcas2p1.samsung.com>
2026-11-06  4:12     ` Kiwoong Kim [this message]
2026-11-06  4:53       ` [PATCH v7 2/2] scsi: ufs: mcq: poll OCS after sq cleanup " Bart Van Assche
2026-11-06 10:43       ` Bean Huo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1af44cd90dca0dd8a9a06d09a254a4e7e0861b2.1793938245.git.kwmad.kim@samsung.com \
    --to=kwmad.kim@samsung.com \
    --cc=alim.akhtar@samsung.com \
    --cc=bvanassche@acm.org \
    --cc=cpgs@samsung.com \
    --cc=h10.kim@samsung.com \
    --cc=hy50.seo@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=kwangwon.min@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stable@vger.kernel.org \
    --cc=stanleyjhu@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®