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. v2: Don't WARN on success (Ville). Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> --- drivers/gpu/drm/i915/i915_gem.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 9650a7b10c5f..9766fa152e05 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 */ @@ -2017,9 +2018,10 @@ int i915_gem_fault(struct vm_fault *vmf) * handler to reset everything when re-faulting in * i915_mutex_lock_interruptible. */ - case 0: case -ERESTARTSYS: case -EINTR: + WARN_ON(!user_fault); + case 0: 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
