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 0/2] scsi: ufs: fix the abort path of device management commands in MCQ mode
Date: Fri, 6 Nov 2026 13:12:45 +0900 [thread overview]
Message-ID: <cover.1793938245.git.kwmad.kim@samsung.com> (raw)
In-Reply-To: <CGME20261106041300epcas2p4a1028afe27a91c8d6167d422c8be1fb1@epcas2p4.samsung.com>
This series fixes how a timed-out device management command (query, NOP)
is aborted in MCQ mode.
Patch 1 makes ufshcd_try_to_abort_task() skip the task management path
for device management commands and clear them with ufshcd_clear_cmd()
directly. ufshcd_mcq_abort() sends these commands to
the QUERY TASK / ABORT TASK path, which is meant for SCSI I/O commands.
With this change, the SDB path in ufshcd_abort() no longer needs
its own branch for reserved requests, so that branch is removed.
Patch 2 makes ufshcd_mcq_sq_cleanup() wait for the OCS of a device
management command to be updated after SQ cleanup. UFSHCI does not
specify the order between the OCS update and the SQ_CUS update. Without
the wait, a late completion of the cleaned-up query can complete the
retry of that query too early, which leaves the host controller with two
query contexts and raises IS.UTPES. Each iteration of the wait reaps the
CQ directly, so the wait does not depend on interrupt delivery.
Patch 2 depends on patch 1. Without patch 1, ufshcd_mcq_sq_cleanup() is
reached for a device management command only if the ABORT TASK TMF
succeeds.
Changes since v6:
- Patch 1: Remove the reserved-request branch from ufshcd_abort(), since
ufshcd_try_to_abort_task() now handles device management commands. (Bart)
- Patch 1: Update the kernel-doc of ufshcd_try_to_abort_task() and add
a Closes: tag for the report. (Bart)
- Patch 2: Reap the CQ with ufshcd_mcq_poll_cqe_lock() in each iteration
of the OCS poll, as ufshcd_clear_lu_cmds() does after
ufshcd_clear_cmd(). This removes the dependency on interrupt delivery.
The OCS is still read under hwq->cq_lock, because the interrupt handler
can reap the CQE between the reap and the read. Rename
ufshcd_mcq_read_ocs() to ufshcd_mcq_poll_ocs(). (Bart)
- Patch 2: Rework the commit message. Explain how the problem applies to
the current code and how it affects the retry, quote UFSHCI on the CQE
posted after a successful cleanup, and explain the CQ reaping.
- Add the "scsi:" prefix to the subjects.
Link: https://lore.kernel.org/linux-scsi/20261105004333.1097899-1-kwmad.kim@samsung.com/
Changes since v5:
- Read the OCS under hwq->cq_lock again, as in v4. Without the lock,
ufshcd_mcq_sq_cleanup() can observe the OCS update and return while
ufshcd_compl_one_cqe() has not yet called scsi_done(). A retry that
reuses the reserved request can then be completed by that pending
scsi_done() call (Sashiko).
- Explain the need for cq_lock in a comment and in the patch 2 commit
message.
Link: https://lore.kernel.org/linux-scsi/20261104094914.180788-1-kwmad.kim@samsung.com/
Changes since v4:
- Read the OCS in ufshcd_mcq_sq_cleanup() with READ_ONCE() directly and
drop the cq_lock and the ufshcd_mcq_read_ocs() helper, per review. (Bart)
- Report an error when the OCS poll times out. (Bart)
Link: https://lore.kernel.org/linux-scsi/cover.1793598099.git.kwmad.kim@samsung.com/
Changes since v3:
- Split the v3 patch into two patches: the abort path fix and
the OCS poll after SQ cleanup (Bean Huo).
- Explain in patch 1 that the problem is only reachable since the
scsi_get_internal_cmd() conversion and add the corresponding Fixes tag,
per review.
- Add a Fixes tag to patch 2. (Bean Huo)
- Fix the step numbering of the timeline in the patch 2 commit message.
Link: https://lore.kernel.org/linux-scsi/20261030111045.982094-1-kwmad.kim@samsung.com/
Changes since v2:
- Use read_poll_timeout() for the OCS poll in ufshcd_mcq_sq_cleanup().
The open-coded loop did not re-read the OCS after the timeout, so it
could return a false -ETIMEDOUT if the OCS was updated while sleeping
in the last iteration (Sashiko).
Link: https://lore.kernel.org/linux-scsi/20261030093645.790159-1-kwmad.kim@samsung.com/
Changes since v1:
- Limit the OCS poll in ufshcd_mcq_sq_cleanup() to device management
commands. ufshcd_compl_one_cqe() copies the OCS from the CQE into the
UTRD only for them, so for SCSI commands the poll always ran for
MCQ_POLL_US and then failed with -ETIMEDOUT (Sashiko).
- Return -ETIMEDOUT only if OCS is still OCS_INVALID_COMMAND_STATUS
after the poll. OCS_ABORTED, which the host controller reports for
the cleaned-up request, is no longer treated as a cleanup failure
(Sashiko).
- Update the commit message to match.
Link: https://lore.kernel.org/linux-scsi/20261030083311.602909-1-kwmad.kim@samsung.com/
Kiwoong Kim (2):
scsi: ufs: core: skip ABORT TASK for device management commands
scsi: ufs: mcq: poll OCS after sq cleanup for device management
commands
drivers/ufs/core/ufs-mcq.c | 34 ++++++++++++++++++++++++++++++++++
drivers/ufs/core/ufshcd.c | 23 ++++++++++++++---------
2 files changed, 48 insertions(+), 9 deletions(-)
--
2.43.0
next 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 ` Kiwoong Kim [this message]
[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 ` [PATCH v7 2/2] scsi: ufs: mcq: poll OCS after sq cleanup " Kiwoong Kim
2026-11-06 4:53 ` 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=cover.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®