From: "Kiwoong Kim" <kwmad.kim@samsung.com>
To: "'Bart Van Assche'" <bvanassche@acm.org>, <linux-scsi@vger.kernel.org>
Subject: RE: [PATCH v4 2/2] ufs: mcq: poll OCS after sq cleanup for device management commands
Date: Wed, 4 Nov 2026 14:22:30 +0900 [thread overview]
Message-ID: <000a01dd6c1c$7d786830$78693890$@samsung.com> (raw)
In-Reply-To: <703c41b5-537f-4897-b852-fed4097a0193@acm.org>
> > +static enum utp_ocs ufshcd_mcq_read_ocs(struct ufs_hw_queue *hwq,
> > + struct ufshcd_lrb *lrbp)
> > +{
> > + guard(spinlock_irqsave)(&hwq->cq_lock);
> > + return READ_ONCE(lrbp->utr_descriptor_ptr->header.ocs);
> > +}
>
> READ_ONCE() is sufficient. I don't think that the spinlock helps here.
> Additionally, if the spinlock operations are left out, the function
> ufshcd_mcq_read_ocs() is no longer necessary and can be inlined in its
> only caller.
>
It seems like your proposal works in terms of reading OCS,
but I guess there could be a race at a nearly same time among different CPUs
because UFS driver uses the same tag # for device commands.
Of course, it would take CPU C long to reach up to clearing cmd->state,
so that what the timeline shows will be unlikely to happen, I think.
I was just concerned about the possibility.
Anyway, let me take your proposal to revise this.
WITHOUT cq_lock
CPU A: ISR CPU B: Error handler CPU C: IO thread
---------- --------------- -------------------
set OCS
READ_ONCE sees OCS
scsi_prepare_cmd()
-> clears cmd->state
scsi_done(cmd)
-> cmd->state is set to SCMD_STATE_COMPLETE and test_and_set_bit returns non zero
(cmd->state is already set when the cmd is timed-out)
-> blk_mq_complete_request called (Unexpected)
WITH cq_lock
CPU A: ISR CPU B: Error handler CPU C: IO thread
-------------------------- --------------- -------------------
set OCS
lock(cq_lock) ...waits...
scsi_done(cmd)
-> cmd->state is set to SCMD_STATE_COMPLETE and test_and_set_bit returns 0
-> just return
unlock(cq_lock)
lock acquired
READ_ONCE sees OCS
scsi_prepare_cmd()
-> clears cmd->state
> > + err = read_poll_timeout(ufshcd_mcq_read_ocs, ocs,
> > + ocs != OCS_INVALID_COMMAND_STATUS, 20,
> > + MCQ_POLL_US, false, hwq, lrbp);
> > + }
>
> An error message should be reported if the above loop times out.
Got it.
>
> Thanks,
>
> Bart.
Kiwoong Kim
BRs.
prev parent reply other threads:[~2026-11-04 5:22 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 ` [PATCH v4 0/2] ufs: fix the abort path of device management commands in MCQ mode Kiwoong Kim
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 [this message]
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='000a01dd6c1c$7d786830$78693890$@samsung.com' \
--to=kwmad.kim@samsung.com \
--cc=bvanassche@acm.org \
--cc=linux-scsi@vger.kernel.org \
/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