From: Matthew Auld <matthew.auld@intel.com>
To: Ilia Levi <ilia.levi@intel.com>, intel-xe@lists.freedesktop.org
Cc: koby.elbaz@intel.com, shuicheng.lin@intel.com,
thomas.hellstrom@intel.com,
Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH v2 5/5] drm/xe/mmio_gem: fix destroy flow
Date: Tue, 21 Jul 2026 10:15:08 +0100 [thread overview]
Message-ID: <b0b43e2c-e6a5-4082-82be-216ec7d56942@intel.com> (raw)
In-Reply-To: <ad9d424d-9b9a-4c27-bbec-58a293fed39c@intel.com>
On 16/07/2026 16:22, Matthew Auld wrote:
> On 26/05/2026 13:51, Ilia Levi wrote:
>> xe_mmio_gem_destroy() currently frees the GEM object directly, bypassing
>> reference counting. Since existing VMAs hold a reference and the fault
>> handler accesses the object through vma->vm_private_data, this is
>> use-after-free. Additionally, nothing prevents the fault handler from
>> installing PTEs to the real MMIO after destroy.
>>
>> Use SRCU to ensure the fault handler sees the 'destroyed' flag
>> (mirroring the drm_dev_enter/exit pattern for hot-unplug), then zap
>> existing PTEs to prevent continued access to the real MMIO. Use
>> drm_gem_object_put() to respect the reference count.
>
> Couple questions here:
>
> 1) Can we not just use the dma-resv for synchronisation? We wrap the
> mmio_gem with a gem buffer, so the dma-resv is already there. This has
> the added benefit of looking more similar to the normal bo fault path.
> Also same question for dummy_page_lock in the previous patch.
>
> 2) Should we not just SIGBUG, if something faults on this post destroy?
> Is this not a userspace issue? Re-routing to the dummy page on unplug
> makes sense, since userspace did nothing wrong, so we want to give it a
> chance to recover.
For 2) other option is maybe just to drop the gem->destroyed handling
for now. For PCI_BARRIER and anything else tied to the xe_file, there
shouldn't be any weird lifetime issues, so it should be impossible to
see something "destroyed" in the fault handler. It's otherwise hard to
judge without seeing a real user for this special "destroyed" flow with
the re-routing to a dummy page.
>
>>
>> Fixes: 1ffcf8b8ae8a ("drm/xe: Support for mmap-ing mmio regions")
>> Assisted-by: GitHub-Copilot:claude-opus-4.6
>> Signed-off-by: Ilia Levi <ilia.levi@intel.com>
>> ---
>> drivers/gpu/drm/xe/xe_mmio_gem.c | 27 ++++++++++++++++++++++++++-
>> 1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/xe_mmio_gem.c b/drivers/gpu/drm/xe/
>> xe_mmio_gem.c
>> index 2f2ebc4fd901..b91704c51a93 100644
>> --- a/drivers/gpu/drm/xe/xe_mmio_gem.c
>> +++ b/drivers/gpu/drm/xe/xe_mmio_gem.c
>> @@ -5,11 +5,15 @@
>> #include "xe_mmio_gem.h"
>> +#include <linux/srcu.h>
>> +
>> #include <drm/drm_drv.h>
>> #include <drm/drm_gem.h>
>> #include "xe_device_types.h"
>> +DEFINE_STATIC_SRCU(xe_mmio_gem_srcu);
>> +
>> /**
>> * DOC: Exposing MMIO regions to userspace
>> *
>> @@ -39,6 +43,7 @@ struct xe_mmio_gem {
>> unsigned long pgoff;
>> struct mutex dummy_page_lock; /* protects dummy page allocation */
>> struct page *dummy_page;
>> + bool destroyed;
>> };
>> static const struct vm_operations_struct vm_ops = {
>> @@ -145,8 +150,23 @@ static void xe_mmio_gem_free(struct
>> drm_gem_object *base)
>> */
>> void xe_mmio_gem_destroy(struct xe_mmio_gem *gem, struct drm_file
>> *file)
>> {
>> + struct drm_gem_object *base = &gem->base;
>> + struct drm_device *dev = base->dev;
>> +
>> drm_vma_node_revoke(&gem->base.vma_node, file);
>> - xe_mmio_gem_free(&gem->base);
>> +
>> + gem->destroyed = true;
>> + synchronize_srcu(&xe_mmio_gem_srcu);
>> +
>> + /*
>> + * At this point every subsequent fault handler will see that the
>> + * object has been destroyed and provide the dummy page.
>> + * Now just zap existing PTEs to prevent continued access to the
>> real
>> + * MMIO.
>> + */
>> + drm_vma_node_unmap(&base->vma_node, dev->anon_inode->i_mapping);
>> +
>> + drm_gem_object_put(base);
>> }
>> static int xe_mmio_gem_mmap(struct drm_gem_object *base, struct
>> vm_area_struct *vma)
>> @@ -196,6 +216,11 @@ static vm_fault_t xe_mmio_gem_vm_fault(struct
>> vm_fault *vmf)
>> unsigned long pgoff;
>> int idx;
>> + guard(srcu)(&xe_mmio_gem_srcu);
>> +
>> + if (obj->destroyed)
>> + return xe_mmio_gem_vm_fault_dummy_page(vmf);
>> +
>> if (!drm_dev_enter(dev, &idx)) {
>> /*
>> * Provide a dummy page to avoid SIGBUS for events such as
>> hot-unplug.
>
next prev parent reply other threads:[~2026-07-21 9:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 12:51 [PATCH v2 0/5] drm/xe/mmio_gem: fix fault handler and destroy path Ilia Levi
2026-05-26 12:51 ` [PATCH v2 1/5] drm/xe/mmio_gem: use write-back mapping for dummy page Ilia Levi
2026-05-26 12:51 ` [PATCH v2 2/5] drm/xe/mmio_gem: fix fault handling for split VMA Ilia Levi
2026-07-15 13:05 ` Matthew Auld
2026-07-21 3:20 ` Matthew Brost
2026-07-21 8:44 ` Matthew Auld
2026-07-21 11:49 ` Levi, Ilia
2026-07-21 13:19 ` Matthew Auld
2026-07-21 17:35 ` Matthew Brost
2026-07-21 18:45 ` Levi, Ilia
2026-05-26 12:51 ` [PATCH v2 3/5] drm/xe/mmio_gem: Revoke drm_vma_node on xe_mmio_gem destroy Ilia Levi
2026-05-26 12:51 ` [PATCH v2 4/5] drm/xe/mmio_gem: cache the dummy page per object Ilia Levi
2026-05-26 12:51 ` [PATCH v2 5/5] drm/xe/mmio_gem: fix destroy flow Ilia Levi
2026-07-16 15:22 ` Matthew Auld
2026-07-21 9:15 ` Matthew Auld [this message]
2026-07-21 15:00 ` Levi, Ilia
2026-05-26 12:58 ` ✓ CI.KUnit: success for drm/xe/mmio_gem: fix fault handler and destroy path (rev2) Patchwork
2026-05-26 13:42 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-26 15:20 ` ✓ Xe.CI.FULL: " Patchwork
2026-07-16 15:55 ` [PATCH v2 0/5] drm/xe/mmio_gem: fix fault handler and destroy path Matthew Auld
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=b0b43e2c-e6a5-4082-82be-216ec7d56942@intel.com \
--to=matthew.auld@intel.com \
--cc=ilia.levi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=koby.elbaz@intel.com \
--cc=matthew.brost@intel.com \
--cc=shuicheng.lin@intel.com \
--cc=thomas.hellstrom@intel.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.