On Tue, Oct 07, 2014 at 06:10:57PM +0100, Michel Thierry wrote:
> From: Ben Widawsky <benjamin.widawsky@xxxxxxxxx>
>
> Signed-off-by: Ben Widawsky <ben@xxxxxxxxxxxx>
> Signed-off-by: Michel Thierry <michel.thierry@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_gem_evict.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 886ff2e..7fd8b9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -214,6 +214,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle)
> struct i915_vma *vma, *next;
> int ret;
>
> + BUG_ON(!mutex_is_locked(&vm->dev->struct_mutex));
No BUG_ON if it means a potential soft failure becomes a hard failure. A
lot of our code runs (at least a driver load time) under the console_lock.
Which means that if you die with a BUG your system is completely dead.
WARN_ON is perfectly fine here.
-Daniel
> trace_i915_gem_evict_vm(vm);
>
> if (do_idle) {
> @@ -222,6 +223,8 @@ int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle)
> return ret;
>
> i915_gem_retire_requests(vm->dev);
> +
> + WARN_ON(!list_empty(&vm->active_list));
> }
>
> list_for_each_entry_safe(vma, next, &vm->inactive_list, mm_list)
> --
> 2.0.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
