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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox