[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.

Cc: Matthew Wilcox <willy at infradead.org>
Cc: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter at 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