[PATCH 9/9] drm/amdgpu: Lock the attached dmabuf in unpopulate

Christian König christian.koenig at amd.com
Wed Apr 14 07:33:51 UTC 2021


Am 14.04.21 um 08:46 schrieb Felix Kuehling:
> amdgpu_ttm_tt_unpopulate can be called during bo_destroy. The dmabuf->resv
> must not be held by the caller or dma_buf_detach will deadlock. This is
> probably not the right fix. I get a recursive lock warning with the
> reservation held in ttm_bo_release. Should unmap_attachment move to
> backend_unbind instead?

Yes probably, but I'm really wondering if we should call unpopulate 
without holding the reservation lock.

Christian.

>
> Signed-off-by: Felix Kuehling <Felix.Kuehling at amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 936b3cfdde55..257750921eed 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1216,9 +1216,22 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_device *bdev,
>   
>   	if (ttm->sg && gtt->gobj->import_attach) {
>   		struct dma_buf_attachment *attach;
> +		bool locked;
>   
>   		attach = gtt->gobj->import_attach;
> +		/* FIXME: unpopulate can be called during bo_destroy.
> +		 * The dmabuf->resv must not be held by the caller or
> +		 * dma_buf_detach will deadlock. This is probably not
> +		 * the right fix. I get a recursive lock warning with the
> +		 * reservation held in ttm_bo_releas.. Should
> +		 * unmap_attachment move to backend_unbind instead?
> +		 */
> +		locked = dma_resv_is_locked(attach->dmabuf->resv);
> +		if (!locked)
> +			dma_resv_lock(attach->dmabuf->resv, NULL);
>   		dma_buf_unmap_attachment(attach, ttm->sg, DMA_BIDIRECTIONAL);
> +		if (!locked)
> +			dma_resv_unlock(attach->dmabuf->resv);
>   		ttm->sg = NULL;
>   		return;
>   	}



More information about the dri-devel mailing list