drm/gma500: Use correct unref in the gem bo create function

2016-02-18 Thread Patrik Jakobsson
Please apply the following patch to stable 4.4. Seems we can hit this on CDV without an evil userspace. Fixes a warning and a race. commit d3e376f52d095103ca51dbda4d6ff8aaf488f98f Author: Daniel Vetter Date: Mon Nov 23 10:32:49 2015 +0100 drm/gma500: Use correct unref in the gem bo create

[PATCH 16/29] drm/gma500: Use correct unref in the gem bo create function

2015-11-23 Thread Daniel Vetter
This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter --- drive

[PATCH RESEND 07/20] drm/gma500: Use correct unref in the gem bo create function

2015-11-19 Thread Daniel Vetter
This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson Acked-by: Patrik Jakobsson Signed-off-by: Daniel Vetter --- drive

[PATCH 12/25] drm/gma500: Use correct unref in the gem bo create function

2015-10-15 Thread Patrik Jakobsson
On Thu, Oct 15, 2015 at 9:36 AM, Daniel Vetter wrote: > This is called without dev->struct_mutex held, we need to use the > _unlocked variant. > > Never caught in the wild since you'd need an evil userspace which > races a gem_close ioctl call with the in-progress open. > > Signed-off-by: Daniel

[PATCH 12/25] drm/gma500: Use correct unref in the gem bo create function

2015-10-15 Thread Daniel Vetter
This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/gma500/gem.c | 2 +- 1 file changed, 1