summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorIlia Levi <ilia.levi@intel.com>2026-09-08 17:50:53 +0100
committerMatthew Auld <matthew.auld@intel.com>2026-09-09 10:57:10 +0100
commitfb2ee38bab8025ad6a7a9cbb4635c5a178e4a7bc (patch)
treeabbaa4922cd2d7480c3654baf5f49fbced009830 /tools/perf/scripts/python
parent8bf6213f9831e46313af4722a1ee6db1b7596378 (diff)
downloadlinux-fb2ee38bab8025ad6a7a9cbb4635c5a178e4a7bc.tar.gz
linux-fb2ee38bab8025ad6a7a9cbb4635c5a178e4a7bc.zip
drm/xe/mmio_gem: fix destroy flow
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. Fix this with proper synchronization and refcounting. Also, do not set vm_pgoff to zero. Many DRM drivers do this because helpers like dma_mmap_pages() interpret vm_pgoff as an intra-buffer page offset; leaving the DRM fake offset there would break these helpers. Those drivers can get away with zeroing it because they map eagerly - all PTEs are established before mmap returns, so vm_pgoff is never consulted again. Our driver does not use such helpers and the newly introduced call to drm_vma_node_unmap() relies on vm_pgoff being untouched. v2: (Matt Auld) - use dma_resv lock to serialize fault handler with destroy - SIGBUS on access after destroy 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> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260908165046.1393557-16-matthew.auld@intel.com
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions