[Intel-gfx] [PATCH] drm/i915: WARN if we hit a signal from kernel context

[Daniel Vetter]

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 at infradead.org>
Cc: Chris Wilson <chris at chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
---
 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