On 29/11/2019 13:59, Boris Brezillon wrote:
If 2 threads change the MADVISE property of the same BO in parallel we might end up with an shmem->madv value that's inconsistent with the presence of the BO in the shrinker list.
I'm a bit worried from the point of view of user space sanity that you observed this - but clearly the kernel should be robust!
The easiest solution to fix that is to protect the drm_gem_shmem_madvise() call with the shrinker lock.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon boris.brezillon@collabora.com
Reviewed-by: Steven Price steven.price@arm.com
drivers/gpu/drm/panfrost/panfrost_drv.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c index f21bc8a7ee3a..efc0a24d1f4c 100644 --- a/drivers/gpu/drm/panfrost/panfrost_drv.c +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c @@ -347,20 +347,19 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, void *data, return -ENOENT; }
- mutex_lock(&pfdev->shrinker_lock); args->retained = drm_gem_shmem_madvise(gem_obj, args->madv);
if (args->retained) { struct panfrost_gem_object *bo = to_panfrost_bo(gem_obj);
mutex_lock(&pfdev->shrinker_lock);- if (args->madv == PANFROST_MADV_DONTNEED)
list_add_tail(&bo->base.madv_list, &pfdev->shrinker_list);
list_add_tail(&bo->base.madv_list,&pfdev->shrinker_list);
mutex_unlock(&pfdev->shrinker_lock);
- mutex_unlock(&pfdev->shrinker_lock);
drm_gem_object_put_unlocked(gem_obj); return 0;