Received-SPF: pass (google.com: domain of linux-kernel+bounces-166419-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Thu, 2 May 2024 14:00:12 +0200
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: =?UTF-8?B?QWRyacOhbg==?= Larumbe <adrian.larumbe@collabora.com>, Qiang
 Yu <yuq825@gmail.com>, Maarten Lankhorst
 <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>,
 David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, Rob
 Herring <robh@kernel.org>, Steven Price <steven.price@arm.com>, Sumit
 Semwal <sumit.semwal@linaro.org>, Christian Koenig=
 <christian.koenig@amd.com>, Dmitry Osipenko
 <dmitry.osipenko@collabora.com>, Zack Rusin <zack.rusin@broadcom.com>,
 kernel@collabora.com, dri-devel@lists.freedesktop.org,
 lima@lists.freedesktop.org, linux-kernel@vger.kernel.org,
 linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH v3 0/2] drm: Fix dma_resv deadlock at drm object pin
 time
Message-ID: <20240502140012.68e88831@collabora.com>
In-Reply-To: <20240502135941.136ad639@collabora.com>
References: <20240501065650.2809530-1-adrian.larumbe@collabora.com>
	<84a5f7b6-d20a-4c69-83a8-d8394fea2b68@suse.de>
	<20240502135941.136ad639@collabora.com>
Organization: Collabora
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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