From: Nicolin Chen <nicolinc@nvidia.com>
To: <jgg@nvidia.com>, <kevin.tian@intel.com>
Cc: <iommu@lists.linux.dev>, <linux-kernel@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>
Subject: [PATCH rc v3 2/4] iommufd: Move vevent memory allocation outside spinlock
Date: Mon, 25 May 2026 11:51:22 -0700 [thread overview]
Message-ID: <ac2d7ab700eca8bbaea62b3e1e327d21249bb9a8.1779734952.git.nicolinc@nvidia.com> (raw)
In-Reply-To: <cover.1779734952.git.nicolinc@nvidia.com>
The veventq memory allocation happens inside the spinlock. Given its depth
is decided by the user space, this leaves a vulnerability, where userspace
can allocate large queues to exhaust atomic memory reserves.
Move the allocation outside the spinlock and use GFP_NOWAIT, which can fail
fast under memory pressure without dipping into the GFP_ATOMIC reserves or
direct-reclaiming from the threaded IRQ handler. On allocation failure,
queue the lost_events_header (so userspace learns of the drop) and return
-ENOMEM so the caller learns of the kernel-side memory pressure.
This is intentionally distinct from the queue-overflow path, which also
queues the lost_events_header but returns 0: a full queue is an expected
userspace-pacing condition rather than a kernel error.
A subsequent change will cap the upper bound of the veventq_depth.
Fixes: e36ba5ab808e ("iommufd: Add IOMMUFD_OBJ_VEVENTQ and IOMMUFD_CMD_VEVENTQ_ALLOC")
Cc: stable@vger.kernel.org
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/iommu/iommufd/driver.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommufd/driver.c b/drivers/iommu/iommufd/driver.c
index 61e6b02601d1a..3b8067976eac0 100644
--- a/drivers/iommu/iommufd/driver.c
+++ b/drivers/iommu/iommufd/driver.c
@@ -149,15 +149,18 @@ int iommufd_viommu_report_event(struct iommufd_viommu *viommu,
goto out_unlock_veventqs;
}
- spin_lock(&veventq->common.lock);
- if (veventq->num_events == veventq->depth) {
+ /* Pre-allocate to avoid GFP_ATOMIC; use GFP_NOWAIT to avoid sleeping */
+ vevent = kzalloc_flex(*vevent, event_data, data_len, GFP_NOWAIT);
+ if (!vevent) {
+ spin_lock(&veventq->common.lock);
vevent = &veventq->lost_events_header;
+ rc = -ENOMEM;
goto out_set_header;
}
- vevent = kzalloc_flex(*vevent, event_data, data_len, GFP_ATOMIC);
- if (!vevent) {
- rc = -ENOMEM;
+ spin_lock(&veventq->common.lock);
+ if (veventq->num_events == veventq->depth) {
+ kfree(vevent);
vevent = &veventq->lost_events_header;
goto out_set_header;
}
--
2.43.0
next prev parent reply other threads:[~2026-05-25 18:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 18:51 [PATCH rc v3 0/4] iommufd: Fix veventq_depth boundary Nicolin Chen
2026-05-25 18:51 ` [PATCH rc v3 1/4] iommufd: Fix data_len byte-count vs element-count mismatch Nicolin Chen
2026-05-25 18:51 ` Nicolin Chen [this message]
2026-05-25 18:51 ` [PATCH rc v3 3/4] iommufd: Set veventq_depth upper bound Nicolin Chen
2026-05-25 18:51 ` [PATCH rc v3 4/4] iommufd/selftest: Add boundary tests for veventq_depth Nicolin Chen
2026-06-01 12:07 ` [PATCH rc v3 0/4] iommufd: Fix veventq_depth boundary Jason Gunthorpe
2026-06-01 18:27 ` Nicolin Chen
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=ac2d7ab700eca8bbaea62b3e1e327d21249bb9a8.1779734952.git.nicolinc@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@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
all inboxes | Powered by JetHome®