From patchwork Thu May 23 11:32:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Adri=C3=A1n_Larumbe?= X-Patchwork-Id: 798816 Received: from madrid.collaboradmins.com (madrid.collaboradmins.com [46.235.227.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8CD4C13D2B8; Thu, 23 May 2024 11:32:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.227.194 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716463972; cv=none; b=KsKubckLPJVZRAT9LaQdvvyfjzldDIfx79pPVLklLCP6/Dl7pGEqqGidrgcaGsA5HXLHiqxb1wC1K07ymji1Z+6LuZSmHUF3QvrbJLfOGtE6ZBkyWUyxkMQUJTDeNr514ys7ewnYMFDioJEZjVxhHqyhLEJO3Hywie04VNXYOFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716463972; c=relaxed/simple; bh=B7CVT8mlKuRo1bPhSO+NfICxEbWVkkWyIjUuF91f8aw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GPy6820WSSVVeyusGxzosVrczCRCYkjMiWX2MhIZ7B+iA1Zdi7YLcdCzoZz4Zxp99KhVVWTIMSgmfXjFziOqQ1r9VgDnhtki/H9f7EDcQ7AsTmjhlLC8PhmZOikubpfwMnSG5bHfF25PhGXvhoLwU4nuoPzOqbPryEEaDPoWnvA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=x4Y8JkMF; arc=none smtp.client-ip=46.235.227.194 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="x4Y8JkMF" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1716463968; bh=B7CVT8mlKuRo1bPhSO+NfICxEbWVkkWyIjUuF91f8aw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x4Y8JkMFb8i8j7iYu+YrCshcbgAKeN6kjXyvCslJLxr7n9wvamyT17habbScqtHsa ogWa6mvRtaoeWZ0u/A/Ng0oqoYlXgW0Z58o2Gc6aJ9WKaI1uhIE8cBCKVHgo1U0sEI D2uYK//XHzPp/q4i9ZjN6sxcvOdNyHMgQhgIuEzWK9FqRn5Z6x3/9ZLx4Sym0HQAsU 0xc+BH5H9CBGrYiu7vYuhG7AFaG6MkOq0uxtHd8nZ5/MTJeQb7wUBUAGO/2Pyyxbn+ TuLnCgG+P8/2CnB0SdOYr9ERwzImkfOH5uor1E8bNnv2Pmx6PJGm1nefOJy+9zc2bx IlbCi+GjQ5mFQ== Received: from localhost.localdomain (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alarumbe) by madrid.collaboradmins.com (Postfix) with ESMTPSA id 00BB837821B9; Thu, 23 May 2024 11:32:47 +0000 (UTC) From: =?utf-8?q?Adri=C3=A1n_Larumbe?= To: Boris Brezillon , Rob Herring , Steven Price , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Sumit Semwal , =?utf-8?q?Christian_K=C3=B6nig?= , Dmitry Osipenko , Zack Rusin Cc: kernel@collabora.com, =?utf-8?q?Adri=C3=A1n_Larumbe?= , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org Subject: [PATCH v4 1/3] drm/panfrost: Fix dma_resv deadlock at drm object pin time Date: Thu, 23 May 2024 12:32:17 +0100 Message-ID: <20240523113236.432585-2-adrian.larumbe@collabora.com> X-Mailer: git-send-email 2.45.1 In-Reply-To: <20240523113236.432585-1-adrian.larumbe@collabora.com> References: <20240523113236.432585-1-adrian.larumbe@collabora.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 When Panfrost must pin an object that is being prepared a dma-buf attachment for on behalf of another driver, the core drm gem object pinning code already takes a lock on the object's dma reservation. However, Panfrost GEM object's pinning callback would eventually try taking the lock on the same dma reservation when delegating pinning of the object onto the shmem subsystem, which led to a deadlock. This can be shown by enabling CONFIG_DEBUG_WW_MUTEX_SLOWPATH, which throws the following recursive locking situation: weston/3440 is trying to acquire lock: ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_pin+0x34/0xb8 [drm_shmem_helper] but task is already holding lock: ffff000000e235a0 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_pin+0x2c/0x80 [drm] Fix it by replacing drm_gem_shmem_pin with its locked version, as the lock had already been taken by drm_gem_pin(). Cc: Thomas Zimmermann Cc: Dmitry Osipenko Cc: Boris Brezillon Cc: Steven Price Fixes: a78027847226 ("drm/gem: Acquire reservation lock in drm_gem_{pin/unpin}()") Signed-off-by: Adrián Larumbe --- drivers/gpu/drm/panfrost/panfrost_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c index d47b40b82b0b..8e0ff3efede7 100644 --- a/drivers/gpu/drm/panfrost/panfrost_gem.c +++ b/drivers/gpu/drm/panfrost/panfrost_gem.c @@ -192,7 +192,7 @@ static int panfrost_gem_pin(struct drm_gem_object *obj) if (bo->is_heap) return -EINVAL; - return drm_gem_shmem_pin(&bo->base); + return drm_gem_shmem_pin_locked(&bo->base); } static enum drm_gem_object_status panfrost_gem_status(struct drm_gem_object *obj)