All of lore.kernel.org
 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 v4 0/2] ufs: fix the abort path of device management commands in MCQ mode
Date: Mon,  2 Nov 2026 14:52:56 +0900	[thread overview]
Message-ID: <cover.1793598099.git.kwmad.kim@samsung.com> (raw)
In-Reply-To: CGME20261102055313epcas2p236ca7854da996b968f37931db6e5258b@epcas2p2.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, as the single doorbell path in ufshcd_abort() already does.
Since the conversion to scsi_get_internal_cmd(), ufshcd_mcq_abort() sends
these commands to the QUERY TASK / ABORT TASK path, which is meant for
SCSI I/O commands.

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 race with the
retry of that query, which leaves the host with two query contexts and
raises IS.UTPES.

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 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):
  ufs: core: skip ABORT TASK for device management commands
  ufs: mcq: poll OCS after sq cleanup for device management commands

 drivers/ufs/core/ufs-mcq.c | 21 +++++++++++++++++++++
 drivers/ufs/core/ufshcd.c  |  4 ++++
 2 files changed, 25 insertions(+)

-- 
2.43.0


       reply	other threads:[~2026-11-02  5:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20261102055313epcas2p236ca7854da996b968f37931db6e5258b@epcas2p2.samsung.com>
2026-11-02  5:52 ` Kiwoong Kim [this message]
2026-11-02  5:52   ` [PATCH v4 1/2] ufs: core: skip ABORT TASK for device management commands Kiwoong Kim
2026-11-03 22:55     ` Bean Huo
2026-11-04  4:34     ` Bart Van Assche
2026-11-02  5:52   ` [PATCH v4 2/2] ufs: mcq: poll OCS after sq cleanup " Kiwoong Kim
2026-11-04  1:46     ` Bart Van Assche
2026-11-04  5:22       ` Kiwoong Kim

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.1793598099.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.