[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240502135941.136ad639@collabora.com>
Date: Thu, 2 May 2024 13:59:41 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: Adrián Larumbe <adrian.larumbe@...labora.com>, Qiang
Yu <yuq825@...il.com>, Maarten Lankhorst
<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>, Rob
Herring <robh@...nel.org>, Steven Price <steven.price@....com>, Sumit
Semwal <sumit.semwal@...aro.org>, Christian Koenig=
<christian.koenig@....com>, Dmitry Osipenko
<dmitry.osipenko@...labora.com>, Zack Rusin <zack.rusin@...adcom.com>,
kernel@...labora.com, dri-devel@...ts.freedesktop.org,
lima@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin
time
Hi Thomas,
On Thu, 2 May 2024 13:51:16 +0200
Thomas Zimmermann <tzimmermann@...e.de> wrote:
> Hi,
>
> ignoring my r-b on patch 1, I'd like to rethink the current patches in
> general.
>
> I think drm_gem_shmem_pin() should become the locked version of _pin(),
> so that drm_gem_shmem_object_pin() can call it directly. The existing
> _pin_unlocked() would not be needed any longer. Same for the _unpin()
> functions. This change would also fix the consistency with the semantics
> of the shmem _vmap() functions, which never take reservation locks.
>
> There are only two external callers of drm_gem_shmem_pin(): the test
> case and panthor. These assume that drm_gem_shmem_pin() acquires the
> reservation lock. The test case should likely call drm_gem_pin()
> instead. That would acquire the reservation lock and the test would
> validate that shmem's pin helper integrates well into the overall GEM
> framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me.
> For now, it could receive a wrapper that takes the lock and that's it.
I do agree that the current inconsistencies in the naming is
troublesome (sometimes _unlocked, sometimes _locked, with the version
without any suffix meaning either _locked or _unlocked depending on
what the suffixed version does), and that's the very reason I asked
Dmitry to address that in his shrinker series [1]. So, ideally I'd
prefer if patches from Dmitry's series were applied instead of
trying to fix that here (IIRC, we had an ack from Maxime).
Regards,
Boris
Powered by blists - more mailing lists