From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Paul Menzel <paulepanter@users.sourceforge.net>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling
Date: Wed, 19 Dec 2012 18:21:10 +0100 [thread overview]
Message-ID: <50D1F786.3020300@canonical.com> (raw)
In-Reply-To: <50D1CCCB.1070205@canonical.com>
Op 19-12-12 15:18, Maarten Lankhorst schreef:
> Fix regression introduced by 85b144f860176
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
> Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
>
Hey Paul Menzel,
I just wanted to have the fix out asap, and had to leave right after.
Updated commit message below:
Fix regression introduced by 85b144f860176
"drm/ttm: call ttm_bo_cleanup_refs with reservation and lru lock held, v3"
Slowpath ttm_bo_cleanup_refs_and_unlock accidentally tried to increase
refcount on &bo->sync_obj instead of bo->sync_obj.
The compiler didn't complain since sync_obj_ref takes a void pointer,
so it was still valid c.
This could result in lockups, memory corruptions, and warnings like
these when graphics card VRAM usage is high:
------------[ cut here ]------------
WARNING: at include/linux/kref.h:42 radeon_fence_ref+0x2c/0x40()
Hardware name: System Product Name
Pid: 157, comm: X Not tainted 3.7.0-rc7-00520-g85b144f-dirty #174
Call Trace:
[<ffffffff81058c84>] ? warn_slowpath_common+0x74/0xb0
[<ffffffff8129273c>] ? radeon_fence_ref+0x2c/0x40
[<ffffffff8125e95c>] ? ttm_bo_cleanup_refs_and_unlock+0x18c/0x2d0
[<ffffffff8125f17c>] ? ttm_mem_evict_first+0x1dc/0x2a0
[<ffffffff81264452>] ? ttm_bo_man_get_node+0x62/0xb0
[<ffffffff8125f4ce>] ? ttm_bo_mem_space+0x28e/0x340
[<ffffffff8125fb0c>] ? ttm_bo_move_buffer+0xfc/0x170
[<ffffffff810de172>] ? kmem_cache_alloc+0xb2/0xc0
[<ffffffff8125fc15>] ? ttm_bo_validate+0x95/0x110
[<ffffffff8125ff7c>] ? ttm_bo_init+0x2ec/0x3b0
[<ffffffff8129419a>] ? radeon_bo_create+0x18a/0x200
[<ffffffff81293e80>] ? radeon_bo_clear_va+0x40/0x40
[<ffffffff812a5342>] ? radeon_gem_object_create+0x92/0x160
[<ffffffff812a575c>] ? radeon_gem_create_ioctl+0x6c/0x150
[<ffffffff812a529f>] ? radeon_gem_object_free+0x2f/0x40
[<ffffffff81246b60>] ? drm_ioctl+0x420/0x4f0
[<ffffffff812a56f0>] ? radeon_gem_pwrite_ioctl+0x20/0x20
[<ffffffff810f53a4>] ? do_vfs_ioctl+0x2e4/0x4e0
[<ffffffff810e5588>] ? vfs_read+0x118/0x160
[<ffffffff810f55ec>] ? sys_ioctl+0x4c/0xa0
[<ffffffff810e5851>] ? sys_read+0x51/0xa0
[<ffffffff814b0612>] ? system_call_fastpath+0x16/0x1b
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Message-ID: <20121217182752.GA351@x4>
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0bf66f9..9f85418 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -579,7 +579,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
* at this point the buffer should be dead, so
* no new sync objects can be attached.
*/
- sync_obj = driver->sync_obj_ref(&bo->sync_obj);
+ sync_obj = driver->sync_obj_ref(bo->sync_obj);
spin_unlock(&bdev->fence_lock);
atomic_set(&bo->reserved, 0);
next prev parent reply other threads:[~2012-12-19 17:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 14:18 [PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling Maarten Lankhorst
2012-12-19 14:33 ` Markus Trippelsdorf
2012-12-20 13:30 ` Alex Deucher
2012-12-20 13:45 ` Markus Trippelsdorf
2012-12-20 13:58 ` Markus Trippelsdorf
2013-01-05 10:41 ` Markus Trippelsdorf
2013-01-15 14:43 ` Michel Dänzer
2013-01-15 15:23 ` Markus Trippelsdorf
2013-01-15 15:26 ` Michel Dänzer
2013-01-15 16:32 ` Markus Trippelsdorf
2013-01-15 17:03 ` Markus Trippelsdorf
2013-01-16 22:36 ` Alex Deucher
2013-01-16 23:10 ` Markus Trippelsdorf
2013-01-17 0:18 ` Jerome Glisse
2013-01-17 8:46 ` Markus Trippelsdorf
2013-01-17 15:44 ` Jerome Glisse
2013-01-17 16:10 ` Markus Trippelsdorf
2013-01-17 17:55 ` Jerome Glisse
2013-01-17 18:07 ` Markus Trippelsdorf
2013-01-17 18:28 ` Jerome Glisse
2013-01-17 18:57 ` Markus Trippelsdorf
2012-12-19 14:41 ` Paul Menzel
2012-12-19 14:47 ` Alex Deucher
2012-12-19 14:54 ` Markus Trippelsdorf
2012-12-19 16:03 ` Markus Trippelsdorf
2012-12-19 17:21 ` Maarten Lankhorst [this message]
2012-12-19 18:40 ` Paul Menzel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50D1F786.3020300@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=paulepanter@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.