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 <willy@xxxxxxxxxxxxx> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
