From: <gregkh@linuxfoundation.org>
To: gregkh@linuxfoundation.org, intel-xe@lists.freedesktop.org,
jacek.lawrynowicz@linux.intel.com, jani.nikula@intel.com,
lucas.demarchi@intel.com, matthew.auld@intel.com,
matthew.brost@intel.com, michal.wajdeczko@intel.com,
nirmoy.das@intel.com, rodrigo.vivi@intel.com,
thomas.hellstrom@linux.intel.com, tomasz.rusinowicz@intel.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "drm/xe: Fix exporting xe buffers multiple times" has been added to the 6.13-stable tree
Date: Mon, 24 Mar 2025 09:13:46 -0700 [thread overview]
Message-ID: <2025032445-amiss-distant-5798@gregkh> (raw)
This is a note to let you know that I've just added the patch titled
drm/xe: Fix exporting xe buffers multiple times
to the 6.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-xe-fix-exporting-xe-buffers-multiple-times.patch
and it can be found in the queue-6.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From 50af7cab7520e46680cf4633bba6801443b75856 Mon Sep 17 00:00:00 2001
From: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com>
Date: Tue, 18 Feb 2025 11:03:53 +0100
Subject: drm/xe: Fix exporting xe buffers multiple times
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com>
commit 50af7cab7520e46680cf4633bba6801443b75856 upstream.
The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but
it was incorrectly tested for XE_PL_* flags.
This caused xe_dma_buf_pin() to always fail when invoked for
the second time. Fix this by checking the `mem_type` field instead.
Fixes: 7764222d54b7 ("drm/xe: Disallow pinning dma-bufs in VRAM")
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Nirmoy Das <nirmoy.das@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: intel-xe@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.8+
Signed-off-by: Tomasz Rusinowicz <tomasz.rusinowicz@intel.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250218100353.2137964-1-jacek.lawrynowicz@linux.intel.com
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
(cherry picked from commit b96dabdba9b95f71ded50a1c094ee244408b2a8e)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/xe/xe_bo.h | 2 --
drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/gpu/drm/xe/xe_bo.h
+++ b/drivers/gpu/drm/xe/xe_bo.h
@@ -318,7 +318,6 @@ static inline unsigned int xe_sg_segment
return round_down(max / 2, PAGE_SIZE);
}
-#if IS_ENABLED(CONFIG_DRM_XE_KUNIT_TEST)
/**
* xe_bo_is_mem_type - Whether the bo currently resides in the given
* TTM memory type
@@ -333,4 +332,3 @@ static inline bool xe_bo_is_mem_type(str
return bo->ttm.resource->mem_type == mem_type;
}
#endif
-#endif
--- a/drivers/gpu/drm/xe/xe_dma_buf.c
+++ b/drivers/gpu/drm/xe/xe_dma_buf.c
@@ -58,7 +58,7 @@ static int xe_dma_buf_pin(struct dma_buf
* 1) Avoid pinning in a placement not accessible to some importers.
* 2) Pinning in VRAM requires PIN accounting which is a to-do.
*/
- if (xe_bo_is_pinned(bo) && bo->ttm.resource->placement != XE_PL_TT) {
+ if (xe_bo_is_pinned(bo) && !xe_bo_is_mem_type(bo, XE_PL_TT)) {
drm_dbg(&xe->drm, "Can't migrate pinned bo for dma-buf pin.\n");
return -EINVAL;
}
Patches currently in stable-queue which might be from tomasz.rusinowicz@intel.com are
queue-6.13/drm-xe-fix-exporting-xe-buffers-multiple-times.patch
reply other threads:[~2025-03-24 16:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=2025032445-amiss-distant-5798@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jacek.lawrynowicz@linux.intel.com \
--cc=jani.nikula@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=nirmoy.das@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stable-commits@vger.kernel.org \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tomasz.rusinowicz@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.