On Mon, 2026-08-31 at 11:11 +0530, Srinivasan Shanmugam wrote: > When a GPU dma-fence signals, drivers often need to perform work that > cannot run in IRQ context. This pattern is currently open-coded in > multiple drivers. > > This series introduces two layered helpers: > > Patch 1 introduces drm_work_fence — a generic embeddable base > structure > that handles the dma-fence-callback-to-workqueue pattern. Any driver > needing deferred fence work can use this directly. > > Patch 2 introduces drm_user_fence — a thin layer on top of > drm_work_fence that adds kthread_use_mm() support for drivers that > need > to access userspace memory when a fence signals. > > Patch 3 converts XE to use drm_user_fence. XE continues to write a > fence completion value to a userspace VA using the new helper. > > Patch 4 adds optional per-signal compare functionality to > drm_user_fence. > When cmp_addr is set, the worker is called only if the value at > cmp_addr > satisfies the configured comparison. This enables AMDGPU's EOP > eventfd > per-signal filtering without open-coding the read+compare pattern. > > A follow-on patch (not in this series) will wire AMDGPU's render-node > EOP eventfd signaling path to drm_work_fence. > > v5: > - Split drm_user_fence into drm_work_fence (generic) and > drm_user_fence > (MM-borrowing subclass) per Matthew Brost's suggestion. > - Add per-signal compare functionality > (drm_user_fence_set_compare()) > per Christian König's suggestion. > - Use mmput_async() instead of mmput() to avoid potential deadlock > in > MMU notifier release path. (Sashiko review) > > Suggested-by: Matthew Brost <[email protected]> > Suggested-by: Christian König <[email protected]> > Cc: Mika Kuoppala <[email protected]> > Cc: Thomas Hellström <[email protected]> > Cc: Maarten Lankhorst <[email protected]> > Cc: [email protected] > Cc: [email protected] > Cc: [email protected]
I think the get_user() and put_user() of 64-bit values in drm (driver common) code is not safe for typical use-cases on 32-bit systems. For xe we officially don't (yet at least) support 32-bit systems so hence the code is a bit sloppy but for drm helpers I'm not sure we can get away with this. At least not without some form of warning or assert. I think to make 32-bit systems 64-bit user-fence safe, we would need to user pin_user_pages() combined with cmpxchg64() and a similar cmpxchg operation on the user-space side. Thanks, Thomas > > Srinivasan Shanmugam (4): > drm: Add drm_work_fence helper > drm: Add drm_user_fence helper > drm/xe: Convert xe_user_fence to drm_user_fence > drm: Add per-signal compare functionality to drm_user_fence > > drivers/gpu/drm/Makefile | 2 + > drivers/gpu/drm/drm_user_fence.c | 147 ++++++++++++++++++++++ > drivers/gpu/drm/drm_work_fence.c | 195 > +++++++++++++++++++++++++++++ > drivers/gpu/drm/xe/xe_sync.c | 149 ++++++++++++---------- > drivers/gpu/drm/xe/xe_sync.h | 2 + > drivers/gpu/drm/xe/xe_sync_types.h | 1 - > drivers/gpu/drm/xe/xe_vm.c | 1 + > include/drm/drm_user_fence.h | 115 +++++++++++++++++ > include/drm/drm_work_fence.h | 76 +++++++++++ > 9 files changed, 619 insertions(+), 69 deletions(-) > create mode 100644 drivers/gpu/drm/drm_user_fence.c > create mode 100644 drivers/gpu/drm/drm_work_fence.c > create mode 100644 include/drm/drm_user_fence.h > create mode 100644 include/drm/drm_work_fence.h
