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