From: sashiko-bot@kernel.org
To: "Matthew Auld" <matthew.auld@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/xe: don't allocate fake mmap offsets for imported dma-bufs
Date: Sat, 07 Nov 2026 17:43:26 +0000 [thread overview]
Message-ID: <sashiko-outbox-203124@kernel.org> (raw)
In-Reply-To: <20261107-oom-fun-v1-1-be9eb05b82ed@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] drm/xe: bogus offset 0 in drm_gem_ttm_dumb_map_offset() for
imported BOs
--
commit f6897baa0037e7c5c3efac24443f4046494f642e
Author: Matthew Auld <matthew.auld@intel.com>
drm/xe: don't allocate fake mmap offsets for imported dma-bufs
This commit removes the drm_vma_offset node from imported dma-buf buffer
objects after initialization and rejects objects without a valid vma_node
in xe_gem_mmap_offset_ioctl().
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index 42a6aa1a2e4a0..0181f73ef66d0 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -3851,6 +3851,12 @@ int xe_gem_mmap_offset_ioctl(struct drm_device *dev, void *data,
> if (XE_IOCTL_DBG(xe, !gem_obj))
> return -ENOENT;
>
> + /* Imported dma-bufs have no mmap offset since CPU access is rejected. */
> + if (XE_IOCTL_DBG(xe, !drm_vma_node_size(&gem_obj->vma_node))) {
> + xe_bo_put(gem_to_xe_bo(gem_obj));
> + return -EINVAL;
> + }
> +
> /* The mmap offset was set up at BO allocation time. */
> args->offset = drm_vma_node_offset_addr(&gem_obj->vma_node);
>
> diff --git a/drivers/gpu/drm/xe/xe_dma_buf.c b/drivers/gpu/drm/xe/xe_dma_buf.c
> index 5bf13dc4b61d8..17a8663a68de0 100644
> --- a/drivers/gpu/drm/xe/xe_dma_buf.c
> +++ b/drivers/gpu/drm/xe/xe_dma_buf.c
> @@ -12,6 +12,7 @@
>
> #include <drm/drm_device.h>
> #include <drm/drm_prime.h>
> +#include <drm/drm_vma_manager.h>
> #include <drm/ttm/ttm_tt.h>
>
> #include "tests/xe_test.h"
> @@ -353,6 +354,14 @@ xe_dma_buf_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
> }
> drm_gem_object_put(dummy_obj);
>
> + /*
> + * CPU faults on imported BOs are rejected, so there is no point in
> + * consuming fake mmap offset space for them.
> + */
> + if (!ret)
> + drm_vma_offset_remove(bo->ttm.bdev->vma_manager,
> + &bo->ttm.base.vma_node);
> +
> return ret ? ERR_PTR(ret) : &bo->ttm.base;
> }
[Severity: Medium]
Does removing vma_node here cause DRM_IOCTL_MODE_MAP_DUMB on an imported
dma-buf handle to succeed with a bogus offset of 0?
regular_driver sets .dumb_map_offset = drm_gem_ttm_dumb_map_offset, which
does not check drm_gem_is_imported() or drm_vma_node_size() before reading
the offset:
drivers/gpu/drm/drm_gem_ttm_helper.c:drm_gem_ttm_dumb_map_offset() {
...
*offset = drm_vma_node_offset_addr(&gem->vma_node);
drm_gem_object_put(gem);
return 0;
}
With bo->ttm.base.vma_node zeroed by drm_vma_offset_remove(),
drm_gem_ttm_dumb_map_offset() returns 0 with *offset = 0 instead of
-EINVAL.
Also, because xe_bo_init_locked() -> ttm_bo_init_reserved() still
transiently allocates the vma_node for ttm_bo_type_sg before
xe_dma_buf_create_obj() removes it, importing a dma-buf can still fail
with -ENOSPC when bdev->vma_manager is already full or fragmented.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-oom-fun-v1-0-be9eb05b82ed@intel.com?part=1
next prev parent reply other threads:[~2026-11-07 17:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 17:26 [PATCH 0/3] Spurious OOM with P2P dma-buf imports on multi-GPU systems Matthew Auld
2026-11-07 17:26 ` [PATCH 1/3] drm/xe: don't allocate fake mmap offsets for imported dma-bufs Matthew Auld
2026-11-07 17:43 ` sashiko-bot [this message]
2026-11-07 17:26 ` [PATCH 2/3] drm/xe: Exclude imported dma-buf BOs from the TT budget Matthew Auld
2026-11-07 17:36 ` sashiko-bot
2026-11-07 17:26 ` [PATCH 3/3] drm/ttm, drm/xe: Drop the ttm_tt on null moves to VRAM Matthew Auld
2026-11-07 17:36 ` ✓ CI.KUnit: success for Spurious OOM with P2P dma-buf imports on multi-GPU systems Patchwork
2026-11-07 18:10 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-08 8:22 ` ✓ Xe.CI.FULL: " Patchwork
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=sashiko-outbox-203124@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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