From: fangyu.yu@linux.alibaba.com
To: tomasz.jeznach@linux.dev, joro@8bytes.org, will@kernel.org,
robin.murphy@arm.com, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, baolu.lu@linux.intel.com,
jroedel@suse.de, zong.li@sifive.com
Cc: fangyu.yu@linux.alibaba.com, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: [PATCH 0/3] iommu/riscv: Fix command queue publishing races
Date: Mon, 17 Aug 2026 22:27:25 +0800 [thread overview]
Message-ID: <20260817142728.61783-1-fangyu.yu@linux.alibaba.com> (raw)
From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
This series fixes races in the RISC-V IOMMU command queue submission
path.
The current command queue code reserves a producer index before the
command is written and before the hardware tail is updated. Multiple CPUs
can therefore reserve different producer indexes concurrently and then
wait for the software tail to reach their index before publishing their
own command.
That model is fragile when a command submission fails after reserving an
index. The failed producer index is never published, so later submitters
can wait behind a hole in the software producer stream. This can also
lead to misleading IOFENCE.C completion timeouts, because the sync path
may wait for a producer index whose command was never actually enqueued.
Fix this by serializing command queue publishing with a raw spinlock.
Instead of reserving producer indexes ahead of time, the submission path
uses the current software tail as the next command index, writes the
command, publishes the hardware tail, and then advances the software tail
while holding the lock. When the command queue is full, the code drops
the lock and waits for hardware consumption before retrying, so other CPUs
are not blocked behind a long hardware poll.
The final patch changes the queue submission helper to return an error
when enqueue fails. The IOFENCE.C sync path then avoids waiting for a
command that was never published to hardware.
This series does not attempt to add full RAS/error recovery for command
queue failures. It keeps the existing local error reporting behavior and
only fixes the software queue state and wait semantics.
Fangyu Yu (3):
iommu/riscv: Add command queue lock
iommu/riscv: Serialize command queue publishing
iommu/riscv: Avoid waiting on failed command enqueue
drivers/iommu/riscv/iommu.c | 121 ++++++++++++++++++++++--------------
drivers/iommu/riscv/iommu.h | 2 +
2 files changed, 76 insertions(+), 47 deletions(-)
--
2.50.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next reply other threads:[~2026-08-17 14:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 14:27 fangyu.yu [this message]
2026-08-17 14:27 ` [PATCH 1/3] iommu/riscv: Add command queue lock fangyu.yu
2026-08-17 14:27 ` [PATCH 2/3] iommu/riscv: Serialize command queue publishing fangyu.yu
2026-08-17 14:27 ` [PATCH 3/3] iommu/riscv: Avoid waiting on failed command enqueue fangyu.yu
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=20260817142728.61783-1-fangyu.yu@linux.alibaba.com \
--to=fangyu.yu@linux.alibaba.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tomasz.jeznach@linux.dev \
--cc=will@kernel.org \
--cc=zong.li@sifive.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