Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.
> 


  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