Linaro-mm-sig May 2026

linaro-mm-sig@lists.linaro.org

79 participants
70 discussions

[PATCH] dma-buf: Move dma_resv_assert_held() after input validation

by lirongqing

From: Li RongQing <lirongqing(a)baidu.com> Move dma_resv_assert_held() after the validation of 'attach' and 'attach->dmabuf' to avoid a potential null pointer dereference if the function is ever called with invalid arguments. Signed-off-by: Li RongQing <lirongqing(a)baidu.com> --- drivers/dma-buf/dma-buf-mapping.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff..e6ecd6c 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -102,12 +102,12 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t i; int ret; - dma_resv_assert_held(attach->dmabuf->resv); - if (WARN_ON(!attach || !attach->dmabuf || !provider)) /* This function is supposed to work on MMIO memory only */ return ERR_PTR(-EINVAL); + dma_resv_assert_held(attach->dmabuf->resv); + dma = kzalloc_obj(*dma); if (!dma) return ERR_PTR(-ENOMEM); -- 2.9.4

5 months, 2 weeks

Re: DEPT (the dependency tracker) as AI review prompt?

by Yunseong Kim

Hi Harry, On 5/23/26 16:34, Harry Yoo wrote: > > > On 5/23/26 11:00 PM, Yunseong Kim wrote: >> I've previously experimented with running DEPT alongside syzkaller fuzzing, >> and many hung tasks missed by lockdep are caught by DEPT, but the resulting >> high volume of reports makes it easy for issues to get lost in the massive >> log output. Sorting through that output manually is a huge bottleneck, so >> leveraging a well-crafted AI prompt to triage the warnings and filter out >> the false positives would be incredibly valuable. > > I mean both 1) detection of deadlock issues AND 2) false positive elimination with AI. I completely agree. Implanting DEPT's model into an AI review prompt is a great idea. As you suggested, the patterns we develop for the AI could provide valuable feedback to enhance DEPT's itself. > If the review prompt is only used to eliminate DEPT's false positives, I think that would be quite hard to get broad use. > > Someone would have to build out-of-tree DEPT, collect the reports, and then feed those back into the AI. I don't think building that kind of pipeline would actually work well in practice. I also have a huge dept report of DEPT reports, and manually reviewing all of them is makes me sigh. The constant kernel rebuilds required for lockup testing every time are also quite expensive. Thanks for the summary! Best Regards, Yunseong

5 months, 3 weeks

[PATCH v5 0/2] dma-buf: heaps: system: add an option to allocate explicitly shared/decrypted memory

by Jiri Pirko

From: Jiri Pirko <jiri(a)nvidia.com> Confidential computing (CoCo) VMs/guests, such as AMD SEV and Intel TDX, run with private/encrypted memory which creates a challenge for devices that do not support DMA to it (no TDISP support). For kernel-only DMA operations, swiotlb bounce buffering provides a transparent solution by copying data through shared memory. However, the only way to get this memory into userspace is via the DMA API's dma_alloc_pages()/dma_mmap_pages() type interfaces which limits the use of the memory to a single DMA device, and is incompatible with pin_user_pages(). These limitations are particularly problematic for the RDMA subsystem which makes heavy use of pin_user_pages() and expects flexible memory usage between many different DMA devices. This patch series enables userspace to explicitly request shared (decrypted) memory allocations from new dma-buf system_cc_shared heap. Userspace can mmap this memory and pass the dma-buf fd to other existing importers such as RDMA or DRM devices to access the memory. The DMA API is improved to allow the dma heap exporter to DMA map the shared memory to each importing device. Based on dma-mapping-for-next e7442a68cd1ee797b585f045d348781e9c0dde0d Jiri Pirko (2): dma-mapping: introduce DMA_ATTR_CC_SHARED for shared memory dma-buf: heaps: system: add system_cc_shared heap for explicitly shared memory drivers/dma-buf/heaps/system_heap.c | 103 ++++++++++++++++++++++++++-- include/linux/dma-mapping.h | 10 +++ include/trace/events/dma.h | 3 +- kernel/dma/direct.h | 14 +++- kernel/dma/mapping.c | 13 +++- 5 files changed, 132 insertions(+), 11 deletions(-) -- 2.51.1

5 months, 3 weeks

[PATCH v4] drm/virtio: use uninterruptible resv lock for plane updates

by Deepanshu Kartikey

virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable(a)vger.kernel.org Signed-off-by: Deepanshu Kartikey <kartikey406(a)gmail.com> --- v4: Rename the helper to virtio_gpu_lock_one_resv_uninterruptible() and reject objs->nents > 1 with -EINVAL. The v3 helper's multi-object branch used drm_gem_lock_reservations(), which is interruptible, contradicting the "uninterruptible" name; both fix sites lock a single BO so the multi-object path is dropped. (Dmitry Osipenko) v3: Drop the prepare_fb/cleanup_fb approach from v2 (it deadlocked against virtio_gpu_resource_flush(), which also locks the BO in the same atomic commit). Instead add an uninterruptible variant of the resv lock helper and use it in both virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(). (Dmitry Osipenko) v2: Move resv lock acquisition from .atomic_update (which must not fail) to .prepare_fb (which may), per maintainer review of v1. The v1 approach of silently skipping the cursor update on lock failure violated the atomic-commit contract with userspace. --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + drivers/gpu/drm/virtio/virtgpu_gem.c | 17 +++++++++++++++++ drivers/gpu/drm/virtio/virtgpu_plane.c | 10 ++++++++-- 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index f17660a71a3e..2f3531950aa4 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -317,6 +317,7 @@ virtio_gpu_array_from_handles(struct drm_file *drm_file, u32 *handles, u32 nents void virtio_gpu_array_add_obj(struct virtio_gpu_object_array *objs, struct drm_gem_object *obj); int virtio_gpu_array_lock_resv(struct virtio_gpu_object_array *objs); +int virtio_gpu_lock_one_resv_uninterruptible(struct virtio_gpu_object_array *objs); void virtio_gpu_array_unlock_resv(struct virtio_gpu_object_array *objs); void virtio_gpu_array_add_fence(struct virtio_gpu_object_array *objs, struct dma_fence *fence); diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c index f22dc5c21cd4..435d37d36034 100644 --- a/drivers/gpu/drm/virtio/virtgpu_gem.c +++ b/drivers/gpu/drm/virtio/virtgpu_gem.c @@ -238,6 +238,23 @@ int virtio_gpu_array_lock_resv(struct virtio_gpu_object_array *objs) return ret; } +int virtio_gpu_lock_one_resv_uninterruptible(struct virtio_gpu_object_array *objs) +{ + int ret; + + if (objs->nents != 1) + return -EINVAL; + + dma_resv_lock(objs->objs[0]->resv, NULL); + + ret = dma_resv_reserve_fences(objs->objs[0]->resv, 1); + if (ret) { + virtio_gpu_array_unlock_resv(objs); + return ret; + } + return 0; +} + void virtio_gpu_array_unlock_resv(struct virtio_gpu_object_array *objs) { if (objs->nents == 1) { diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index a126d1b25f46..652352424744 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c @@ -215,7 +215,10 @@ static void virtio_gpu_resource_flush(struct drm_plane *plane, if (!objs) return; virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]); - virtio_gpu_array_lock_resv(objs); + if (virtio_gpu_lock_one_resv_uninterruptible(objs)) { + virtio_gpu_array_put_free(objs); + return; + } virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, x, y, width, height, objs, vgplane_st->fence); @@ -459,7 +462,10 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane, if (!objs) return; virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]); - virtio_gpu_array_lock_resv(objs); + if (virtio_gpu_lock_one_resv_uninterruptible(objs)) { + virtio_gpu_array_put_free(objs); + return; + } virtio_gpu_cmd_transfer_to_host_2d (vgdev, 0, plane->state->crtc_w, -- 2.43.0

5 months, 3 weeks

[PATCH V1] Revert "accel/amdxdna: Support read-only user-pointer BO mappings"

by Lizhi Hou

This reverts commit f649e63d4a6423eda8eb208638849fd6396aedd7. The read-only feature requires further consideration. Signed-off-by: Lizhi Hou <lizhi.hou(a)amd.com> --- drivers/accel/amdxdna/amdxdna_ubuf.c | 29 ++-------------------------- 1 file changed, 2 insertions(+), 27 deletions(-) diff --git a/drivers/accel/amdxdna/amdxdna_ubuf.c b/drivers/accel/amdxdna/amdxdna_ubuf.c index 3769210c55cc..4c0647057759 100644 --- a/drivers/accel/amdxdna/amdxdna_ubuf.c +++ b/drivers/accel/amdxdna/amdxdna_ubuf.c @@ -125,26 +125,6 @@ static const struct dma_buf_ops amdxdna_ubuf_dmabuf_ops = { .vunmap = amdxdna_ubuf_vunmap, }; -static int readonly_va_entry(struct amdxdna_drm_va_entry *va_ent) -{ - struct mm_struct *mm = current->mm; - struct vm_area_struct *vma; - int ret; - - mmap_read_lock(mm); - - vma = find_vma(mm, va_ent->vaddr); - if (!vma || - vma->vm_start > va_ent->vaddr || - vma->vm_end - va_ent->vaddr < va_ent->len) - ret = -ENOENT; - else - ret = vma->vm_flags & VM_WRITE ? 0 : 1; - - mmap_read_unlock(mm); - return ret; -} - struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, u32 num_entries, void __user *va_entries) { @@ -154,7 +134,6 @@ struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, struct amdxdna_ubuf_priv *ubuf; u32 npages, start = 0; struct dma_buf *dbuf; - bool readonly = true; int i, ret; DEFINE_DMA_BUF_EXPORT_INFO(exp_info); @@ -193,10 +172,6 @@ struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, ret = -EINVAL; goto free_ent; } - - /* Pin pages as writable as long as not all entries are read-only. */ - if (readonly && readonly_va_entry(&va_ent[i]) != 1) - readonly = false; } ubuf->nr_pages = exp_info.size >> PAGE_SHIFT; @@ -219,7 +194,7 @@ struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, npages = va_ent[i].len >> PAGE_SHIFT; ret = pin_user_pages_fast(va_ent[i].vaddr, npages, - (readonly ? 0 : FOLL_WRITE) | FOLL_LONGTERM, + FOLL_WRITE | FOLL_LONGTERM, &ubuf->pages[start]); if (ret >= 0) { start += ret; @@ -236,7 +211,7 @@ struct dma_buf *amdxdna_get_ubuf(struct drm_device *dev, exp_info.ops = &amdxdna_ubuf_dmabuf_ops; exp_info.priv = ubuf; - exp_info.flags = (readonly ? O_RDONLY : O_RDWR) | O_CLOEXEC; + exp_info.flags = O_RDWR | O_CLOEXEC; dbuf = dma_buf_export(&exp_info); if (IS_ERR(dbuf)) { -- 2.34.1

5 months, 3 weeks

[PATCH] dma-buf: set SB_I_NOEXEC on the pseudo filesystem

by John Hubbard

The dma-buf pseudo filesystem dispenses S_ANON_INODE inodes via alloc_anon_inode() but never sets SB_I_NOEXEC on its superblock. Since commit 1e7ab6f67824 ("anon_inode: rework assertions") in 6.17, path_noexec() warns on exactly that combination, so an mmap() on any dma-buf fd trips the warning: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 dma-bufs have no business being executable, which is the invariant that the new assertion is enforcing. Set SB_I_NOEXEC on the dmabuf superblock. Reproducer on a CONFIG_DEBUG_VFS=y kernel: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system The selftest allocates from /dev/dma_heap/system and mmaps the returned fd, which trips the warning without this patch. Fixes: 1e7ab6f67824 ("anon_inode: rework assertions") Cc: stable(a)vger.kernel.org Signed-off-by: John Hubbard <jhubbard(a)nvidia.com> --- drivers/dma-buf/dma-buf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 71f37544a5c6..d86a99d7b8dc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -216,6 +216,7 @@ static int dma_buf_fs_init_context(struct fs_context *fc) if (!ctx) return -ENOMEM; ctx->dops = &dma_buf_dentry_ops; + fc->s_iflags |= SB_I_NOEXEC; return 0; } -- 2.54.0

5 months, 3 weeks

[PATCH v5 0/4] dma-buf: heaps: Turn heaps into modules

by Maxime Ripard

Hi, The recent introduction of heaps in the optee driver [1] made possible the creation of heaps as modules. It's generally a good idea if possible, including for the already existing system and CMA heaps. The system one is pretty trivial, the CMA is now easy too with the reworks we got in 7.1-r1. Let me know what you think, Maxime 1: https://lore.kernel.org/dri-devel/20250911135007.1275833-4-jens.wiklander@l… Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v5: - Rebase on 7.1-rc1 - Add a patch to enable the heaps in arm64 defconfig - Link to v4: https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-0-e18fda5044… Changes in v4: - Fix compilation failure - Rework to take into account OF_RESERVED_MEM - Fix regression making the default CMA area disappear if not created through the DT - Added some documentation and comments - Link to v3: https://lore.kernel.org/r/20260303-dma-buf-heaps-as-modules-v3-0-24344812c7… Changes in v3: - Squashed cma_get_name and cma_alloc/release patches - Fixed typo in Export dev_get_cma_area commit title - Fixed compilation failure with DMA_CMA but not OF_RESERVED_MEM - Link to v2: https://lore.kernel.org/r/20260227-dma-buf-heaps-as-modules-v2-0-454aee7e06… Changes in v2: - Collect tags - Don't export dma_contiguous_default_area anymore, but export dev_get_cma_area instead - Mentioned that heap modules can't be removed - Link to v1: https://lore.kernel.org/r/20260225-dma-buf-heaps-as-modules-v1-0-2109225a09… --- Maxime Ripard (4): dma-buf: heaps: Export mem_accounting parameter dma-buf: heaps: cma: Turn the heap into a module dma-buf: heaps: system: Turn the heap into a module arm64: defconfig: Enable dma-buf heaps arch/arm64/configs/defconfig | 3 +++ drivers/dma-buf/dma-heap.c | 1 + drivers/dma-buf/heaps/Kconfig | 4 ++-- drivers/dma-buf/heaps/cma_heap.c | 3 +++ drivers/dma-buf/heaps/system_heap.c | 5 +++++ 5 files changed, 14 insertions(+), 2 deletions(-) --- base-commit: 5e9b7d093f3f77cb0af4409559e3d139babfb443 change-id: 20260225-dma-buf-heaps-as-modules-1034b3ec9f2a Best regards, -- Maxime Ripard <mripard(a)kernel.org>

5 months, 3 weeks

[PATCH 0/2] dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases

by Albert Esteve

When sharing a dma-buf between components of different trust levels, the allocator may need to hand a consumer a read-only view of a buffer it holds with read-write access. An example is a camera pipeline where the capture component writes frames into a buffer and needs to pass a read-only handle to a downstream processing component that should not be able to modify the data. However, no such mechanism exists today. The access mode of a dma-buf file descriptor is fixed at export time, and the standard POSIX interfaces for duplicating or changing file descriptors (i.e., dup(2), dup3(2), and fcntl(F_SETFL)) cannot alter the read/write access mode of the copy. One natural candidate would be reopening via /proc/self/fd/<N> with O_RDONLY, which works for regular files. For dma-buf this would fail (that is, if we were to add a new handler for open f_op) with ENXIO because the dmabuf pseudo-filesystem carries SB_NOUSER, which prevents the VFS from opening its files through path-based resolution from userspace. Alternatively, exporting the buffer twice would produce two independent dma_buf instances, which breaks fence synchronization. Therefore we add a new DMA_BUF_IOCTL_DERIVE ioctl, which produces a new file descriptor for an existing dma-buf with a caller-specified subset of the original permissions: ``` struct dma_buf_derive { __u32 flags; __s32 fd; }; struct dma_buf_derive req = { .flags = O_RDONLY | O_CLOEXEC }; ioctl(rw_fd, DMA_BUF_IOCTL_DERIVE, &req); /* req.fd is now a read-only alias of the same buffer */ ``` Permission escalation is rejected with -EACCES. The new fd aliases the same struct dma_buf as the original, same dma_resv, same exporter ops, same underlying memory; so importers attaching to either fd see the same fence timeline and operate on the same object. Access control for which components may receive or pass on restricted descriptors can be layered on top via SELinux file:read and file:write permissions. A shared writable mapping (PROT_WRITE | MAP_SHARED) on the read-only fd is rejected with -EACCES in dma_buf_mmap_internal(). Two small internal adjustments accompany the ioctl: - __dma_buf_list_del() is moved to dma_buf_release() so it fires exactly once on dentry destruction rather than on every file close. - dma_buf_file_release() is updated to call dma_buf_put() only for files that are not the primary dma-buf file. This may not be the best approach, but after considering different options and alternatives (as described above), we decided to raise the discussion upstream. Thus, we welcome any alternative proposal or ideas. The series is structured as: - Patch 1 adds the new ioctl implementation. - Patch 2 adds selftests covering the new ioctl. Signed-off-by: Albert Esteve <aesteve(a)redhat.com> --- Albert Esteve (2): dma-buf: add DMA_BUF_IOCTL_DERIVE for reduced-permission aliases selftests: dma-buf: add DERIVE ioctl tests drivers/dma-buf/dma-buf.c | 58 ++++++++++- include/uapi/linux/dma-buf.h | 28 +++++ tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 114 ++++++++++++++++++++- 3 files changed, 198 insertions(+), 2 deletions(-) --- base-commit: ab5fce87a778cb780a05984a2ca448f2b41aafbf change-id: 20260520-dmabuf-limit-access-73261353841a Best regards, -- Albert Esteve <aesteve(a)redhat.com>

5 months, 3 weeks

[PATCH 0/6] drm/panthor: Use guards

by Boris Brezillon

Turn the mixed bag of manual locks and guards into something more consistent. This patchset takes care of locks that already have guards available, but also adds new guards for resv, drm_dev_enter/exit and the custom panthor_device_resume_and_get() helper we have around runtime PM. I've intentionally placed the patch transition all locks with readily available guards first so we can merge it even if the new guards face some controversy. Signed-off-by: Boris Brezillon <boris.brezillon(a)collabora.com> --- Boris Brezillon (6): drm/panthor: Driver-wide xxx_[un]lock -> [scoped_]guard replacement dma-resv: Define guards for context-less dma_resv locks drm: Define a conditional guard for drm_dev_{enter,exit}() drm/panthor: Use guards for resv locking drm/panthor: Use the drm_dev_access guard drm/panthor: Add a new guard for our custom resume_and_get() PM helper drivers/gpu/drm/panthor/panthor_devfreq.c | 29 +- drivers/gpu/drm/panthor/panthor_device.c | 163 +++++----- drivers/gpu/drm/panthor/panthor_device.h | 10 +- drivers/gpu/drm/panthor/panthor_drv.c | 62 ++-- drivers/gpu/drm/panthor/panthor_gem.c | 102 +++---- drivers/gpu/drm/panthor/panthor_gpu.c | 40 +-- drivers/gpu/drm/panthor/panthor_heap.c | 139 ++++----- drivers/gpu/drm/panthor/panthor_mmu.c | 480 ++++++++++++++---------------- drivers/gpu/drm/panthor/panthor_pwr.c | 8 +- drivers/gpu/drm/panthor/panthor_sched.c | 254 ++++++++-------- include/drm/drm_drv.h | 9 + include/linux/dma-resv.h | 5 + 12 files changed, 589 insertions(+), 712 deletions(-) --- base-commit: ac5ac0acf11df04295eb1811066097b7022d6c7f change-id: 20260512-panthor-guard-refactor-f1c6bc30c321 prerequisite-message-id: 20260512-panthor-signal-from-irq-v2-0-95c614a739cb(a)collabora.com prerequisite-patch-id: e3cfd6399b2dc5439687932c6e961d845369562a prerequisite-patch-id: 79820e6740c0c456efc1dfa273de04e495515a1c prerequisite-patch-id: a3611a7c9551c606aaf87125782e6d18b6a6549e prerequisite-patch-id: 6e9dc83a60e53e7b0d84030727ad9b1921e4b2ca prerequisite-patch-id: eabd36064a01418a6ada3176b996a4038a314c21 prerequisite-patch-id: ca3a30182b71bf66c51ed2b6411d7ed8dc761c8e prerequisite-patch-id: 6e549dd0ee9e3e0c8866da72dcabc82209d88360 prerequisite-patch-id: 5217700df7026ef533a2f273ea2535f9fc1274ac prerequisite-patch-id: 8d57abec9f92bcbb21108d3005805b7c155a48f6 prerequisite-patch-id: 0bf98de955fce577ff8d4fb82c02dc04684beca6 prerequisite-patch-id: a9e0d90a64dfd5950a69b857af3867404be1ab45 Best regards, -- Boris Brezillon <boris.brezillon(a)collabora.com>

5 months, 3 weeks

[PATCH 00/12] misc/syncobj: add /dev/syncobj device

by Julian Orth

This series adds a new device /dev/syncobj that can be used to create and manipulate DRM syncobjs. Previously, these operations required the use of a DRM device and the device needed to support the DRIVER_SYNCOBJ and DRIVER_SYNCOBJ_TIMELINE features. There are several issues with the existing API: - Syncobjs are the only explicit sync mechanism available on wayland. Most compositors do not use GPU waits. Instead, they use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a CPU wait. Being tied to DRM devices means that compositors cannot consistently offer this feature even though no device-specific logic is involved. - llvmpipe currently cannot offer syncobj interop because it does not have access to a DRM device. This means that applications using llvmpipe cannot present images before they have finished rendering, despite llvmpipe using threaded rendering. - Clients that do not use the Vulkan WSI need to manually probe /dev/dri for devices that support the syncobj ioctls in order to use the wayland syncobj protocol. - Similarly, clients that want to use screen capture have no equivalent to the WSI and are therefore forced into that path. - Having to keep a DRM device open has potentially negative interactions with GPU hotplug. - Having to translate between syncobj FDs and handles is troublesome in the compositor usecase since syncobjs come and go frequently and need to be cleaned up when clients disconnect. /dev/syncobj solves these issues by providing all syncobj ioctls under a consistent path that is not tied to any DRM device. It also operates directly on file descriptors instead of syncobj handles. The series starts with a number of small refactorings in drm_syncobj.c to make its functionality available outside of the file and without the need for drm_file/handle pairs. The last commit adds the /dev/syncobj module. I've added it as a misc device but maybe this should instead live somewhere under gpu/drm. An application using the new interface can be found at [1]. [1]: https://github.com/mahkoh/jay/pull/947 --- Julian Orth (12): drm/syncobj: add drm_syncobj_from_fd drm/syncobj: add drm_syncobj_fence_lookup drm/syncobj: make drm_syncobj_array_wait_timeout public drm/syncobj: add drm_syncobj_register_eventfd drm/syncobj: have transfer functions accept drm_syncobj directly drm/syncobj: add drm_syncobj_transfer drm/syncobj: add drm_syncobj_timeline_signal drm/syncobj: add drm_syncobj_query drm/syncobj: fix resource leak in drm_syncobj_import_sync_file_fence drm/syncobj: add drm_syncobj_import_sync_file drm/syncobj: add drm_syncobj_export_sync_file misc/syncobj: add new device Documentation/userspace-api/ioctl/ioctl-number.rst | 1 + drivers/gpu/drm/drm_syncobj.c | 374 ++++++++++++++----- drivers/misc/Kconfig | 10 + drivers/misc/Makefile | 1 + drivers/misc/syncobj.c | 404 +++++++++++++++++++++ include/drm/drm_syncobj.h | 21 ++ include/uapi/linux/syncobj.h | 75 ++++ 7 files changed, 795 insertions(+), 91 deletions(-) --- base-commit: 6916d5703ddf9a38f1f6c2cc793381a24ee914c6 change-id: 20260516-jorth-syncobj-d4d374c8c61b Best regards, -- Julian Orth <ju.orth(a)gmail.com>

5 months, 3 weeks

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig May 2026