[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <TH33ES.VQFJ1AUXO5N81@packett.cool>
Date: Sun, 26 May 2024 05:27:29 -0300
From: Val Packett <val@...kett.cool>
To: Adrián Larumbe <adrian.larumbe@...labora.com>
Cc: Boris Brezillon <boris.brezillon@...labora.com>, Rob Herring
<robh@...nel.org>, Steven Price <steven.price@....com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>, Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>, Zack Rusin
<zack.rusin@...adcom.com>, kernel@...labora.com,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v4 2/3] drm/lima: Fix dma_resv deadlock at drm object pin
time
On Thu, May 23 2024 at 12:32:18 +01:00:00, Adrián Larumbe
<adrian.larumbe@...labora.com> wrote:
> Commit a78027847226 ("drm/gem: Acquire reservation lock in
> drm_gem_{pin/unpin}()") moved locking the DRM object's dma
> reservation to
> drm_gem_pin(), but Lima's pin callback kept calling drm_gem_shmem_pin,
> which also tries to lock the same dma_resv, leading to a double lock
> situation.
>
> As was already done for Panfrost in the previous commit, fix it by
> replacing drm_gem_shmem_pin() with its locked variant.
Hi, just found this while dealing with compositor lockups upon
launching a GL client on an old Rockchip RK3066 tablet, and it did fix
the problem :) Thank you.
Tested-by: Val Packett <val@...kett.cool>
Powered by blists - more mailing lists