From 4cae27411607d8680401faa2fc971d2be0f715fd Mon Sep 17 00:00:00 2001 From: =?utf8?q?Marek=20Ol=C5=A1=C3=A1k?= Date: Mon, 10 Jul 2017 21:59:43 +0200 Subject: [PATCH] radeonsi: prevent a deadlock in util_queue_add_job with too many GL contexts MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit If the queue is full, util_queue_add_job will wait while bo_fence_lock is held. It pb_slab wants to reuse a buffer, it will lock the pb_slab mutex and try to check BO fence busyness, but it has to wait for bo_fence_lock to get released. Both bo_fence_lock and pb_slab mutex are locked now. When the CS thread unreferences and releases a suballocated buffer, it will try to lock the pb_slab mutex and has to wait. The CS thread can't finish its job in order to free a queue slot and unblock util_queue_add_job ==> deadlock. Reviewed-by: Nicolai Hähnle --- src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c index 30f4dfb..837c1e2 100644 --- a/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_winsys.c @@ -316,7 +316,8 @@ amdgpu_winsys_create(int fd, unsigned flags, (void) mtx_init(&ws->global_bo_list_lock, mtx_plain); (void) mtx_init(&ws->bo_fence_lock, mtx_plain); - if (!util_queue_init(&ws->cs_queue, "amdgpu_cs", 8, 1, 0)) { + if (!util_queue_init(&ws->cs_queue, "amdgpu_cs", 8, 1, + UTIL_QUEUE_INIT_RESIZE_IF_FULL)) { amdgpu_winsys_destroy(&ws->base); mtx_unlock(&dev_tab_mutex); return NULL; -- 2.7.4