Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin time

Boris Brezillon
2024-05-02T12:00:15Z

On Thu, 2 May 2024 13:59:41 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:

> Hi Thomas,
>
> On Thu, 2 May 2024 13:51:16 +0200
> Thomas Zimmermann <tzimmermann@suse.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).

With the link this time :-).

[1]https://lore.kernel.org/lkml/20240105184624.508603-1-dmitry.osipenko@collabora.com/T/

>
> Regards,
>
> Boris