[PATCH 0/1] Fix user-fence race issue

[Zbigniew Kempczyński]

I'm adding this cover-letter to explain the reproduction path which
might be useful for reviewers.

Following patch immediately triggers the race. Delay introduced after
writing to signal user-fence reveals it influences on next vm-bind
operation, especially if it is in a sequence:

vm-bind(MAP, addr, ..., ufence)
wait_ufence(ufence)
vm-bind(UNMAP, addr, ..., NULL)

UNMAP operation may start before ufence is released (because it is
part of user_fence_worker()) so we get -EBUSY trying to operate on
same vma (this happens on MAP).

diff --git a/drivers/gpu/drm/xe/xe_sync.c b/drivers/gpu/drm/xe/xe_sync.c
index 8becc3755649..d980b447b014 100644
--- a/drivers/gpu/drm/xe/xe_sync.c
+++ b/drivers/gpu/drm/xe/xe_sync.c
@@ -9,6 +9,7 @@
 #include <linux/kthread.h>
 #include <linux/sched/mm.h>
 #include <linux/uaccess.h>
+#include <linux/delay.h>
 
 #include <drm/drm_print.h>
 #include <drm/drm_syncobj.h>
@@ -81,6 +82,7 @@ static void user_fence_worker(struct work_struct *w)
                kthread_use_mm(ufence->mm);
                if (copy_to_user(ufence->addr, &ufence->value, sizeof(ufence->value)))
                        XE_WARN_ON("Copy to user failed");
+               usleep_range(25000, 30000);
                kthread_unuse_mm(ufence->mm);
                mmput(ufence->mm);
        } else {

Cc: Matthew Brost <matthew.brost at intel.com>
Cc: Matthew Auld <matthew.auld at intel.com>

Zbigniew Kempczyński (1):
  drm/xe/xe_sync: avoid race during ufence signaling

 drivers/gpu/drm/xe/xe_sync.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
2.43.0