From nobody Tue Aug 25 02:40:32 2026 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C10C83B71AA for ; Wed, 8 Jul 2026 15:22:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524132; cv=none; b=lcgapwfp7HlKKzwSiNk/4sySgm6cHg99OwadIRx1IUC2BPaLi3ZvFqxp7h+hb5J6TrD8szlP8sLHOoSWDe12/cdLq+rNjy9DORr+M8XdJFHErK31Lv9MKoZqpXGZOA9Ob+N5YwHioSQcFhrHuxUMQawdyqSnbBvZnspG1waMduk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524132; c=relaxed/simple; bh=bGVUl9LVTT9Wx6pQ9UJrrfOQFpCDoJ4+ZM4JCH35+PA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=D4FKTp8+l5c8Ogoj5psEthLO/fPp9Xfntz/sQTydzSb3BJitA6Q+yVyqe3WrZkE6ZkkAJl/lBrL9yj10M3Zk1tB2g7ld11rcPdYQwi3gPagWt5JG3UZjg6leGOaM++dFuUyTQd791fWAjDsgnzq5REn9o0RgG36dlijoAm1tm9c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=XJLbtqUp; arc=none smtp.client-ip=209.85.218.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="XJLbtqUp" Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-c15d47266baso87505066b.3 for ; Wed, 08 Jul 2026 08:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1783524129; x=1784128929; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=LyC+FmbJe8AFV/pEnbxlDl/WDcANmupwyXjJcuF3JBk=; b=XJLbtqUpL9sdERLWs9igzjRxLyRtt8YO0t1h/PcbpQ63yIf3ZBuTNrzkzvwoByBw6x BPaqQEXMtsz8Hg+d4b081gZsyxDCgZiJJ065uwvMQj6CcfQTSYM7uHkWNCfi3N2I75Xw efbJgPBStv7avTeReCcMPR0t2LAqgXKLwUQZj5NiFk+962wDWtlQgl/g1X0VLh8Pbs7A NZevFfF9uNsFS0AMj+6/1D0q8ohPwZNFfQqFlPzxvu/sxz1yLyR4tcg32ikhwGLEPsSd ZEMbcTYfNjK+05WprpzNIuyMFA8Aco/7vDf4USnSDbBvOtfGMBPKD8u5Nw9Mcc1aTz7c NhQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783524129; x=1784128929; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :content-type:mime-version:subject:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=LyC+FmbJe8AFV/pEnbxlDl/WDcANmupwyXjJcuF3JBk=; b=WGkMU9wJHGJQqmbi2XD/CHVzut4vDBiyd1LSMXlkmZxQ2qJM1v9lz+p97ydZhzMk3z j/7svJA/meR/5Nr1ZzZKlQzx4snOYliVTZaNVw9Oxsm3p7SmgB7ki6b9+QrCgg6gdjyM 0ZNYBM4FYzYuxsyipzPWBVbNfvgknLaXvroK+tClvPGJ/yuKDiFFO4NivdoVI0suvTvI bPO7BETXQ44Jc+Tui6KPzLoB6vAqoVLkMuRk3FDbMBLIj98+o9MxzEVG5S9uydLsSsSr MqyAStFRKZOjVEcKF2vM2NWN50/tAWEP1ax9lyY2lumhoDLyDi/GLsaf9qzmFmHAGErm VylA== X-Forwarded-Encrypted: i=1; AHgh+RoOWNaduOSBgSTBQD6BfcCor05EFqfyFy82tawxLCbyrL8iEwFBsWEM+MlXpbd1zui93XCr+IWsE3OAq8M=@vger.kernel.org X-Gm-Message-State: AOJu0YyWi6tYF3gEKq1rjUTCMiPQcGCudv54Px6ceZBG6ozCh2A/uLYq 7aGLoNBALEt9vlaoHskik/gchnY0qih3ppS1se9mrQIbxpVRpXiDEHnY57s/pf5TM0p9HK4J7G+ l9Ry35UA= X-Gm-Gg: AfdE7cmyRItbp9SgT8kr1puTXFgYA3uMBhqlyKhBeMwviLD7Slz9xPBErJ5e1N7e3XQ lVlhzKraam+Evf5KJJutmh3+LfTYQzT0TXeJzAtrU9W7TK4CoE3AJ5t/MrQHfHKu/C3fFxCsXUj LviudnEr/Ia30eCx0s3N2sN+OUlL1VDs1sKyTcZovkPX9t9TZSKMoxpYHWDzaHNyV06lV1IQp9a lzjtmNWWV/rBmpVVoJ5dUdXq4LXXh/N0vq267rLW/TZQlyqxQCcqdPXwjEFK69inlcA0sU0AeUO z9zfX53rgiiOFoN5w3VeAI9wrCkCKiNocgTC1G/zQ2q9NKgaL52B4GgOlHkGf58CYJJ0YFi9BPj DB4OUrSIpqxvXlvNfjA72cULj+WHSSMZvoRqunjy6fEdIgZ9gr7ZQ+7cuvFUFwq0+2Fc3C9tytP 58OeVfM0Xl3tREgpTLJic3hjRl2Bv8A5hr1r4K05Ofym/ZGJHgHuEuygMzlpyUjiqqbHjzMUSDr fCnUPE= X-Received: by 2002:a17:906:f58f:b0:c12:a992:a6d6 with SMTP id a640c23a62f3a-c15ce000110mr142620966b.23.1783524129106; Wed, 08 Jul 2026 08:22:09 -0700 (PDT) Received: from puffmais2.c.googlers.com (181.179.204.35.bc.googleusercontent.com. [35.204.179.181]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c15beb53b86sm213932966b.25.2026.07.08.08.22.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 08:22:08 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Wed, 08 Jul 2026 16:22:06 +0100 Subject: [PATCH v2 2/2] drm/drm_crtc: fix race with dma_fence_signal() in ::get_driver_name() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260708-linux-drm_crtc_fix2-v2-2-cf72be75d75a@linaro.org> References: <20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@linaro.org> In-Reply-To: <20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@linaro.org> To: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , =?utf-8?q?Christian_K=C3=B6nig?= , Tvrtko Ursulin , Boris Brezillon , Philipp Stanner Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Peter Griffin , Tudor Ambarus , Juan Yescas , kernel-team@android.com, =?utf-8?q?Andr=C3=A9_Draszik?= X-Mailer: b4 0.14.3 Since commit 541c8f2468b9 ("dma-buf: detach fence ops on signal v3"), I'm seeing the BUG_ON() triggering in drm_crtc's fence_to_crtc() via drm_crtc_fence_get_driver_name() regularly: Call trace: panic+0x58/0x5c die+0x160/0x178 bug_brk_handler+0x70/0xa4 call_el1_break_hook+0x3c/0x1a0 do_el1_brk64+0x24/0x74 el1_brk64+0x34/0x54 el1h_64_sync_handler+0x80/0xfc el1h_64_sync+0x84/0x88 drm_crtc_fence_get_driver_name+0x60/0x68 (P) sync_file_get_name+0x184/0x45c sync_file_ioctl+0x404/0xf70 __arm64_sys_ioctl+0x124/0x1dc This looks to be caused by a code flow similar to the following: +++ snip +++ thread A thread B ioctl(SYNC_IOC_FILE_INFO) sync_file_ioctl() sync_file_get_name() dma_fence_signal_timestamp_locked() dma_fence_driver_name() ops =3D rcu_dereference(fence->ops) if (!dma_fence_test_signaled_flag()) ops->get_driver_name(fence) i.e. drm_crtc_fence_get_driver_name() test_and_set_bit(SIGNALED) RCU_INIT_POINTER(fence->ops, NULL) drm_crtc_fence_get_driver_name() BUG_ON(rcu_access_pointer(fence->ops) !=3D &drm_crtc_fence_ops) +++ snap +++ I see two ways to resolve this: a) simply drop the BUG_ON(). It can not work anymore since above commit, as it is racy now. b) pass the original 'ops' pointer obtained in dma_fence_driver_name() to all callees. This patch implements option a), as because: * I don't see much benefit in passing the extra pointer just for this BUG_ON() to work. * Requiring the dma_fence_ops in those callbacks is an implementation detail of the drm_crtc driver, and therefore upper layers shouldn't have to care about that. * The existence of the BUG_ON() doesn't appear to be consistent with implementations of ::get_driver_name() or ::get_timeline_name() in the majority of other DRM drivers in the first place. Those that do have a similar BUG_ON() (i915, xe) probably also need an update similar to this patch here but I'm not in a position to test those. * Using BUG() and friends to take down the system is an unacceptable way to handle a failure as evidenced by many threads on LKML and also in the kernel coding style. Here, the check was presumably added for detecting when something passes an invalid pointer, but that does not happen - and if it could, gracefully handling that situation would be more appropriate. Note that the adjacent drm_crtc_fence_get_timeline_name() has the same problem and is fixed by this patch as well. Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") Signed-off-by: Andr=C3=A9 Draszik Reviewed-by: Philipp Stanner --- v2: - don't turn fence_to_crtc() into macro - update commit message to include reference to unacceptable use of BUG --- drivers/gpu/drm/drm_crtc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index d55f1377ec36..36ae50ddf525 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -154,11 +154,8 @@ static void drm_crtc_crc_fini(struct drm_crtc *crtc) #endif } =20 -static const struct dma_fence_ops drm_crtc_fence_ops; - static struct drm_crtc *fence_to_crtc(struct dma_fence *fence) { - BUG_ON(rcu_access_pointer(fence->ops) !=3D &drm_crtc_fence_ops); return container_of(fence->extern_lock, struct drm_crtc, fence_lock); } =20 --=20 2.55.0.795.g602f6c329a-goog