Re: [Intel-gfx] [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl
2017-05-22 16:59 GMT+03:00 Daniel Vetter :
> I failed to properly onion-wrap the unwind code: We acquire the vblank
> reference before we start with the wait-wound locking dance, hence we
> must make sure we retry before we drop the reference. Oops.
>
> v2: The vblank_put must be after the frambuffer_put (Michel). I suck at
> unwrapping code that doesn't use separate labels for each stage, but
> checks each pointer first ... While re-reading everything I also
> realized that we must clean up the fb refcounts, and specifically
> plane->old_fb before we drop the locks, either in the final unlocking,
> or in the w/w retry path. Hence the correct fix is to drop the
> vblank_put to the very bottom.
>
> Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Reported-by: Tommi Rantala
> Cc: Tommi Rantala
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
Thanks, confirmed that this fixes the warning that I was seeing!
Tested-by: Tommi Rantala
> ---
> drivers/gpu/drm/drm_plane.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index fedd4d60d9cd..5dc8c4350602 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -948,8 +948,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> }
>
> out:
> - if (ret && crtc->funcs->page_flip_target)
> - drm_crtc_vblank_put(crtc);
> if (fb)
> drm_framebuffer_put(fb);
> if (crtc->primary->old_fb)
> @@ -964,5 +962,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
>
> + if (ret && crtc->funcs->page_flip_target)
> + drm_crtc_vblank_put(crtc);
> +
> return ret;
> }
> --
> 2.11.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
2013/3/14 Chris Wilson :
> In order to prevent a potential NULL deference with hostile userspace,
> we need to check whether the ioctl was passed an invalid args pointer.
>
> Reported-by: Tommi Rantala
> Link:
> http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
> Signed-off-by: Chris Wilson
Thanks, looks good. I still see a flood of oopses from the other
ioctls, so it's a bit difficult to test this patch properly.
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 365e41a..9f5602e 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1103,7 +1103,11 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
> struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> int ret, i;
>
> - if (args->buffer_count < 1) {
> + if (args == NULL)
> + return -EINVAL;
> +
> + if (args->buffer_count < 1 ||
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> DRM_DEBUG("execbuf with %d buffers\n", args->buffer_count);
> return -EINVAL;
> }
> @@ -1182,8 +1186,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void
> *data,
> struct drm_i915_gem_exec_object2 *exec2_list = NULL;
> int ret;
>
> + if (args == NULL)
> + return -EINVAL;
> +
> if (args->buffer_count < 1 ||
> - args->buffer_count > UINT_MAX / sizeof(*exec2_list)) {
> + args->buffer_count > INT_MAX / sizeof(*exec2_list)) {
> DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
> return -EINVAL;
> }
> --
> 1.7.10.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer
2013/3/17 Chris Wilson :
> On Mon, Mar 18, 2013 at 07:42:58AM +1000, Dave Airlie wrote:
>> On Mon, Mar 18, 2013 at 7:40 AM, Chris Wilson
>> wrote:
>> > On Sun, Mar 17, 2013 at 08:50:03PM +0100, Daniel Vetter wrote:
>> >> On Sat, Mar 16, 2013 at 11:19 AM, Chris Wilson
>> >> wrote:
>> >> > If *userspace* doesn't request either IOC_IN | IOC_OUT in their ioctl
>> >> > command (which are seperate from the ioctl number), then kdata is set to
>> >> > NULL.
>> >>
>> >> Doesn't that mean that we need these checks everywhere? Or at least a
>> >> fixup in drm core proper?
>> >
>> > That's my conclusion. We either add a flag to ask drm_ioctl to prevent
>> > passing NULL pointers (as the existing behaviour may be useful
>> > somewhere, and I have not checked all callees) or saturate our callbacks
>> > with NULL checks.
>>
>> Do we have the kernel's expected IOC_IN/IOC_OUT flags at that point as well?
>>
>> we could check them and block NULL in that case.
>
> Yes. For the core ioctls, we use drm_ioctls[nr].cmd rather than the
> value passed in by userspace for the IOC_IN|IN_OUT bits. So:
Thanks, trinity can indeed set the in/out bits randomly, in a way that
does not match the driver ioctl definition.
Your patch almost fixes this. For the driver ioctls we will want to
grab the cmd from cmd_drv. So the patch should be:
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 25f91cd..5210f33 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -408,6 +408,7 @@ long drm_ioctl(struct file *filp,
usize = asize = _IOC_SIZE(cmd);
if (drv_size > asize)
asize = drv_size;
+ cmd = ioctl->cmd_drv;
}
else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
ioctl = &drm_ioctls[nr];
Can you please submit this officially?
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 25f91cd..79b8bd1 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -408,6 +408,7 @@ long drm_ioctl(struct file *filp,
> usize = asize = _IOC_SIZE(cmd);
> if (drv_size > asize)
> asize = drv_size;
> + cmd = ioctl->cmd;
> }
> else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
> ioctl = &drm_ioctls[nr];
>
>
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Fix deadlock due to getconnector locking changes
2015-02-24 1:55 GMT+02:00 Marc Finet :
> On Sun, Feb 22, 2015 at 11:38:36AM +0100, Daniel Vetter wrote:
>> In
>>
>> daniel@phenom:~/linux/src$ git show ccfc08655
>> commit ccfc08655d5fd5076828f45fb09194c070f2f63a
>> Author: Rob Clark
>> Date: Thu Dec 18 16:01:48 2014 -0500
>>
>> drm: tweak getconnector locking
>>
>> We need to extend the locking to cover connector->state reading for
>> atomic drivers, but the above commit was a bit too eager and also
>> included the fill_modes callback. Which on i915 on old platforms using
>> load detection needs to acquire modeset locks, resulting in a deadlock
>> on output probing.
>>
>> Reported-by: Marc Finet
>> Cc: Marc Finet
>> Cc: robdcl...@gmail.com
>> Signed-off-by: Daniel Vetter
>
> Tested-by: Marc Finet
>
> Thanks.
>> ---
>> drivers/gpu/drm/drm_crtc.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index b15d720eda4c..ce5f1193ecd6 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -2180,7 +2180,6 @@ int drm_mode_getconnector(struct drm_device *dev, void
>> *data,
>> DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
>>
>> mutex_lock(&dev->mode_config.mutex);
>> - drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>>
>> connector = drm_connector_find(dev, out_resp->connector_id);
>> if (!connector) {
>> @@ -2210,6 +2209,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
>> *data,
>> out_resp->mm_height = connector->display_info.height_mm;
>> out_resp->subpixel = connector->display_info.subpixel_order;
>> out_resp->connection = connector->status;
>> +
>> + drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> encoder = drm_connector_get_encoder(connector);
>> if (encoder)
>> out_resp->encoder_id = encoder->base.id;
>> --
>> 2.1.4
>>
Hi,
I think this patch introduced the following.
If the drm_connector_find() call fails, we jump to the 'out' label and
call drm_modeset_unlock(), before the drm_modeset_lock() call.
[ 59.076011] =
[ 59.076011] [ BUG: bad unlock balance detected! ]
[ 59.076011] 4.0.0-rc1+ #60 Tainted: GW
[ 59.076011] -
[ 59.076011] trinity-c14/2418 is trying to release lock
(crtc_ww_class_mutex) at:
[ 59.076011] [] ww_mutex_unlock+0x42/0xb0
[ 59.076011] but there are no more locks to release!
[ 59.076011]
[ 59.076011] other info that might help us debug this:
[ 59.076011] 1 lock held by trinity-c14/2418:
[ 59.076011] #0: (&dev->mode_config.mutex){+.+.+.}, at:
[] drm_mode_getconnector+0x83/0x400
[ 59.076011]
[ 59.076011] stack backtrace:
[ 59.076011] CPU: 0 PID: 2418 Comm: trinity-c14 Tainted: GW
4.0.0-rc1+ #60
[ 59.076011] Hardware name: Hewlett-Packard HP Compaq dc5750 Small
Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007
[ 59.076011] 81dc2872 88005b777b48 81db6706
[ 59.076011] 88005b719440 88005b777b78 810f8074
001d51c0
[ 59.076011] 880069d3a5d0 88005b719440 81dc2872
88005b777bf8
[ 59.076011] Call Trace:
[ 59.076011] [] ? ww_mutex_unlock+0x42/0xb0
[ 59.076011] [] dump_stack+0x4c/0x65
[ 59.076011] [] print_unlock_imbalance_bug+0xf4/0x100
[ 59.076011] [] ? ww_mutex_unlock+0x42/0xb0
[ 59.076011] [] lock_release_non_nested+0x24e/0x350
[ 59.076011] [] ? mark_held_locks+0x75/0xa0
[ 59.076011] [] ? __mutex_unlock_slowpath+0xad/0x170
[ 59.076011] [] ? ww_mutex_unlock+0x42/0xb0
[ 59.076011] [] lock_release+0xbc/0x380
[ 59.076011] [] __mutex_unlock_slowpath+0x71/0x170
[ 59.076011] [] ? drm_mode_getconnector+0x83/0x400
[ 59.076011] [] ww_mutex_unlock+0x42/0xb0
[ 59.076011] [] drm_modeset_unlock+0x2f/0x40
[ 59.076011] [] drm_mode_getconnector+0x280/0x400
[ 59.076011] [] ? might_fault+0x57/0xb0
[ 59.076011] [] drm_ioctl+0x19c/0x640
[ 59.076011] [] ? trace_hardirqs_on+0xd/0x10
[ 59.076011] [] radeon_drm_ioctl+0x46/0x80
[ 59.076011] [] do_vfs_ioctl+0x318/0x570
[ 59.076011] [] ? selinux_file_ioctl+0x56/0x110
[ 59.076011] [] SyS_ioctl+0x81/0xa0
[ 59.076011] [] system_call_fastpath+0x12/0x17
[ 59.316190] [drm:radeon_gem_pread_ioctl] *ERROR* unimplemented
radeon_gem_pread_ioctl
[ 59.579952] [drm:radeon_info_ioctl] *ERROR* copy_to_user
radeon_info_ioctl:555
[watchdog] kernel became tainted! (512/0) Last seed was 1541132817
Tommi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
Signed-off-by: Tommi Rantala
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..0e9c835 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -270,7 +270,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
#define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
#define DRM_IOCTL_I915_SET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
-#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_SET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
+#define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
#define DRM_IOCTL_I915_GEM_WAITDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] intel_sprite_get_colorkey oops
Hello,
Trinity discovered oopses with the i915 colorkey ioctls, reproducible
on my system with this:
#include
#include
#include
#include
#include
#include
#include
#include
#define GET DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY,
struct drm_intel_sprite_colorkey)
int main(int argc, char **argv)
{
int fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("open");
return 1;
}
for (int i=0; i < 128; ++i) {
printf("get=%d\n", i);
struct drm_intel_sprite_colorkey colorkey = { .plane_id = i };
ioctl(fd, GET, &colorkey);
}
for (int i=0; i < 128; ++i) {
printf("set=%d\n", i);
struct drm_intel_sprite_colorkey colorkey = { .plane_id = i };
ioctl(fd, DRM_IOCTL_I915_SET_SPRITE_COLORKEY, &colorkey);
}
return 0;
}
$ ./main /dev/dri/card0
get=0
get=1
get=2
get=3
get=4
get=5
get=6
get=7
get=8
get=9
get=10
get=11
get=12
get=13
get=14
get=15
get=16
get=17
[ 40.467123] BUG: unable to handle kernel NULL pointer dereference
at (null)
[ 40.475012] IP: [< (null)>] (null)
[ 40.480094] PGD 1728cd067 PUD 17163c067 PMD 0
[ 40.484589] Oops: 0010 [#1] SMP KASAN
[ 40.488297] CPU: 0 PID: 2198 Comm: main Not tainted 4.0.0-rc5+ #87
[ 40.501666] task: 8800c66cd380 ti: 88017279 task.ti:
88017279
[ 40.509179] RIP: 0010:[<>] [< (null)>]
(null)
[ 40.516702] RSP: 0018:880172797d30 EFLAGS: 00010246
[ 40.522037] RAX: ed002e7acbe2 RBX: 88017401d000 RCX: 0007
[ 40.529200] RDX: RSI: 880172797dd8 RDI: 880173d65c00
[ 40.536361] RBP: 880172797d68 R08: R09:
[ 40.543523] R10: R11: R12:
[ 40.550686] R13: 880173d65cd8 R14: 880172797dd8 R15: 880173d65c00
[ 40.557852] FS: 7f09a72e6700() GS:880175c0()
knlGS:
[ 40.565976] CS: 0010 DS: ES: CR0: 80050033
[ 40.571744] CR2: CR3: 00017261c000 CR4: 000406f0
[ 40.578907] Stack:
[ 40.580926] 81b4a437 880172797d68 88017401d000
88017147
[ 40.588394] 0014 fff2 8271c400
880172797e88
[ 40.595864] 818acbbc 880172797e18 8165d7c2
8165d660
[ 40.603335] Call Trace:
[ 40.605797] [] ? intel_sprite_get_colorkey+0x97/0xc0
[ 40.612438] [] drm_ioctl+0x27c/0x890
[ 40.617687] [] ? avc_has_perm+0x182/0x320
[ 40.623371] [] ? avc_has_perm+0x20/0x320
[ 40.628966] [] ? intel_sprite_set_colorkey+0x260/0x260
[ 40.635785] [] ? inode_has_perm.isra.28+0x7c/0xa0
[ 40.642169] [] ? _raw_spin_unlock_irq+0x2b/0x40
[ 40.648376] [] do_vfs_ioctl+0x3cf/0x720
[ 40.653887] [] ? selinux_file_ioctl+0x6a/0x130
[ 40.660008] [] SyS_ioctl+0x81/0xa0
[ 40.665083] [] system_call_fastpath+0x12/0x17
[ 40.671112] Code: Bad RIP value.
[ 40.674465] RIP [< (null)>] (null)
[ 40.679634] RSP
[ 40.683134] CR2:
[ 40.686498] ---[ end trace 9292d9b4aba8dfe9 ]---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Rip out GET_SPRITE_COLORKEY ioctl
2015-03-27 18:42 GMT+02:00 Jani Nikula : > On Fri, 27 Mar 2015, Daniel Vetter wrote: >> On Fri, Mar 27, 2015 at 09:10:02AM +0100, Daniel Vetter wrote: >>> It's completely unused and Tommi noticed that the #define is borked >>> since forever. I've done a git search in userspace and only found >>> broken definitions and no users anywhere. >>> >>> Cc: Tommi Rantala >>> Signed-off-by: Daniel Vetter >> >> Hm Tommi discovered oopses in there, so I guess this should be >> cherry-picked to -fixes+cc: stable too? Jani? > > My OCD really wants to know why this blows up. The get/set functions > look so similar that it feels like the set should fail just the same... > Tommi, did you try just the set part of your test program [1]? Yes, both the set and get ioctls crash: [ 20.868660] BUG: unable to handle kernel NULL pointer dereference at (null) [ 20.876527] IP: [< (null)>] (null) [ 20.881573] PGD c4f7d067 PUD c2a6b067 PMD 0 [ 20.885866] Oops: 0010 [#1] SMP KASAN [ 20.889549] CPU: 1 PID: 2207 Comm: main Not tainted 4.0.0-rc5+ #89 [ 20.902805] task: 8800c4fad380 ti: 8800c2b98000 task.ti: 8800c2b98000 [ 20.910257] RIP: 0010:[<>] [< (null)>] (null) [ 20.917722] RSP: 0018:8800c2b9fd30 EFLAGS: 00010246 [ 20.923012] RAX: ed002e87c961 RBX: 88017463d000 RCX: 0006 [ 20.930116] RDX: dc00 RSI: 8800c2b9fdd8 RDI: 8801743e4800 [ 20.937214] RBP: 8800c2b9fd68 R08: R09: [ 20.944318] R10: R11: R12: 8800c2b9fdd8 [ 20.951416] R13: 8801743e48d8 R14: fffe R15: 8801743e4800 [ 20.958524] FS: 7f7139b3a700() GS:880175e0() knlGS: [ 20.966575] CS: 0010 DS: ES: CR0: 80050033 [ 20.972300] CR2: CR3: c2a67000 CR4: 000406e0 [ 20.979407] Stack: [ 20.981414] 81b4a11d 8800c2b9fd68 88017463d000 8800c4c50c00 [ 20.988838] 0014 fff2 8271c3e0 8800c2b9fe88 [ 20.996238] 818acbbc 8800c2b9fe18 8165d7c2 8165d660 [ 21.003658] Call Trace: [ 21.006110] [] ? intel_sprite_set_colorkey+0xad/0xf0 [ 21.012695] [] drm_ioctl+0x27c/0x890 [ 21.017904] [] ? avc_has_perm+0x182/0x320 [ 21.023544] [] ? avc_has_perm+0x20/0x320 [ 21.029098] [] ? intel_pre_disable_primary+0x90/0x90 [ 21.035690] [] ? inode_has_perm.isra.28+0x7c/0xa0 [ 21.042023] [] do_vfs_ioctl+0x3cf/0x720 [ 21.047488] [] ? selinux_file_ioctl+0x6a/0x130 [ 21.053558] [] SyS_ioctl+0x81/0xa0 [ 21.058595] [] system_call_fastpath+0x12/0x17 [ 21.064580] Code: Bad RIP value. [ 21.067916] RIP [< (null)>] (null) [ 21.073048] RSP [ 21.076524] CR2: [ 21.079863] ---[ end trace 161ba639126f6a45 ]--- [ 274.286068] BUG: unable to handle kernel NULL pointer dereference at (null) [ 274.295149] IP: [< (null)>] (null) [ 274.300242] PGD 171999067 PUD 171b93067 PMD 0 [ 274.304744] Oops: 0010 [#1] SMP KASAN [ 274.308460] CPU: 0 PID: 2202 Comm: main Not tainted 4.0.0-rc5+ #89 [ 274.321856] task: 8801726914e0 ti: 880172928000 task.ti: 880172928000 [ 274.329383] RIP: 0010:[<>] [< (null)>] (null) [ 274.336924] RSP: 0018:88017292fd30 EFLAGS: 00010246 [ 274.342267] RAX: ed002e7bc362 RBX: 88017442f000 RCX: 0007 [ 274.349446] RDX: RSI: 88017292fdd8 RDI: 880173de1800 [ 274.356624] RBP: 88017292fd68 R08: R09: [ 274.363803] R10: R11: R12: [ 274.370979] R13: 880173de18d8 R14: 88017292fdd8 R15: 880173de1800 [ 274.378157] FS: 7f48d6b16700() GS:880175c0() knlGS: [ 274.386297] CS: 0010 DS: ES: CR0: 80050033 [ 274.392078] CR2: CR3: 00017188d000 CR4: 000406f0 [ 274.399257] Stack: [ 274.401280] 81b4a1f7 88017292fd68 88017442f000 880172cc7c00 [ 274.408761] 0014 fff2 8271c3c0 88017292fe88 [ 274.416244] 818acbbc 88017292fe18 8165d7c2 8165d660 [ 274.423727] Call Trace: [ 274.426192] [] ? intel_sprite_get_colorkey+0x97/0xc0 [ 274.432849] [] drm_ioctl+0x27c/0x890 [ 274.438107] [] ? avc_has_perm+0x182/0x320 [ 274.443800] [] ? avc_has_perm+0x20/0x320 [ 274.449407] [] ? intel_sprite_set_colorkey+0xf0/0xf0 [ 274.456065] [] ? inode_has_perm.isra.28+0x7c/0xa0 [ 274.462462] [] do_vfs_ioctl+0x3cf/0x720 [ 274.467984] [] ? selinux_file_ioctl+0x6a/0x130 [ 274.474115] [] SyS_ioctl+0x81/0xa
Re: [Intel-gfx] [PATCH] drm/i915: Reject the colorkey ioctls for primary and cursor planes
2015-03-27 19:59 GMT+02:00 : > From: Ville Syrjälä > > The legcy colorkey ioctls are only implemented for sprite planes, so > reject the ioctl for primary/cursor planes. If we want to support > colorkeying with these planes (assuming we have hw support of course) > we should just move ahead with the colorkey property conversion. > > Cc: Tommi Rantala > Signed-off-by: Ville Syrjälä Thanks, this fixes the oopses I was seeing. Tommi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
