From: "Peter Wang (王信友)" <peter.wang@mediatek.com>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Cc: "quic_asutoshd@guicinc.com" <quic_asutoshd@guicinc.com>
Subject: Re: [PATCH v1] ufs: core: decouple CQE processing from spinlock critical section
Date: Sat, 16 May 2026 06:24:42 +0000 [thread overview]
Message-ID: <bcbfd7a71f698f6a3dcf627d3ea76c79b9897ccf.camel@mediatek.com> (raw)
In-Reply-To: <2ed721de-0410-413a-bda1-99b5313b072d@acm.org>
Hi Bart,
This cannot happen. I think you've missed my point and
are confusing head with tail, and tag with slot.
On Fri, 2026-05-15 at 09:43 -0700, Bart Van Assche wrote
> Hi Peter,
>
> Do you agree that the following can happen with this patch applied
> (assuming there is space for 9 CQEs on completion queues)?
>
> (1) Host allocates tags 0, 1, 2 and 3 and adds the corresponding SQEs
> to
> a submission queue.
>
Tags 0, 1, 2 and 3 in SQ slot 0, 1, 2 and 3
> (2) ufshcd_mcq_poll_cqe_lock() is called from thread context because
> the
> host is polling for completions. The CQ tail is updated but CQE
> processing is delayed, e.g. because the process scheduler
> triggered
> a context switch to another thread.
>
SW can only update CQ head, hence this should be
The CQ head is updated, but CQ slot 0, 1, 2 and 3 processing is delayed
CQ slot 0, 1, 2, 3 is tag 0, 1, 2, 3, CQ head = tail = 4
> (3) The host allocates tags 4, 5, 6 and 7 and sends the corresponding
> commands to the same submission queue.
>
Tags 4, 5, 6 and 7 is in SQ slot 4, 5, 6 and 7
> (4) ufshcd_mcq_poll_cqe_lock() is called because a completion
> interrupt
> has been generated and processes completions for tags 4, 5, 6
> and 7.
> The CQ tail is updated and the CQEs are processed.
Again, SW can only update CQ head, hence this should be
The CQ head is updated and the CQ slot 4, 5, 6, 7 are processed.
CQ slot 4, 5, 6, 7 is tag 4, 5, 6, 7, CQ head = tail = 8
> (5) The host reallocates tags 4, 5, 6 and 7 and writes the
> corresponding
> SQEs to the tail of the submission queue.
>
Here SQ slot 8, 9, 10, 11 is tag 4, 5, 6, 7, Same as CQ if hw finish
it.
> (6) The host controller completes the corresponding commands and
> stores
> the CQEs in CQ slots 8, 0, 1 and 2. Hence, slots 0, 1 and 2 are
> overwritten although the overwritten CQEs have not yet been
> processed.
>
CQ tail is 12 if HW finish, CQ head is 8 after step 4.
Only complete CQ slot 8 , 9, 10, 11, which is tag 4, 5, 6, 7
> (7) The polling code from (2) continues and completes the CQEs in
> slots
> 0, 1, 2 and 3. This causes three of the four of the commands
> from
> (6) to be reported as completed to the block layer although
> these
> have not yet been completed. This will likely trigger data
> corruption.
The polling of tag 0 1 2 3 in CQ slot 0 1 2 3 complete without error.
and SQ tail = SQ head = CQ tail = CQ head = 12
Thanks.
Peter
next prev parent reply other threads:[~2026-05-16 6:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 8:26 [PATCH v1] ufs: core: decouple CQE processing from spinlock critical section peter.wang
2026-05-14 16:22 ` Bart Van Assche
2026-05-15 8:13 ` Peter Wang (王信友)
2026-05-15 16:43 ` Bart Van Assche
2026-05-16 6:24 ` Peter Wang (王信友) [this message]
2026-05-16 14:01 ` Bart Van Assche
2026-05-16 11:52 ` Peter Wang (王信友)
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=bcbfd7a71f698f6a3dcf627d3ea76c79b9897ccf.camel@mediatek.com \
--to=peter.wang@mediatek.com \
--cc=bvanassche@acm.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=quic_asutoshd@guicinc.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.