After a discussion with Wily I got the nagging feeling we might have
some cases of nasty busy loops. The window is fairly small since we
always have a non-faulting fastpath (using page_fault_dis|enable())
first, usually followed by a pile of pending signal checks, before we
go into the slowpath copy_to|from_user that might blow up for real.
Test patch to check what CI thinks of this theory.
Cc: Matthew Wilcox <wi...@infradead.org>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch>
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b10c5f..bf4b0ed70fd2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1902,6 +1902,7 @@ int i915_gem_fault(struct vm_fault *vmf)
struct i915_vma *vma;
pgoff_t page_offset;
unsigned int flags;
+ bool user_fault = vmf->flags & FAULT_FLAG_USER;
int ret;
/* We don't use vmf->pgoff since that has the fake offset */
@@ -2020,6 +2021,7 @@ int i915_gem_fault(struct vm_fault *vmf)
case 0:
case -ERESTARTSYS:
case -EINTR:
+ WARN_ON(!user_fault);
case -EBUSY:
/*
* EBUSY is ok: this just means that another thread
--
2.16.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
