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 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.