From nobody Tue Jul 28 17:20:25 2026 Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 BD5893A9017 for ; Wed, 8 Jul 2026 15:22:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524131; cv=none; b=OFlBwp6ggCxx8Yn3hytl1mIgy2/uSPBdVeQrDCG4Rwuc3N4xduIhQUuCXdSnbPEAu3Na7bjT5k4BT3SfOVeTgcbnyMa73TOsONlUShpaFHDZfLlJ2CsjGUDXkbbJrVj16B+M3/HXnewS2UJCH03OCusXSHb8hLl0r2NS0mYWAQs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524131; c=relaxed/simple; bh=NAe5ipfAWpbnz6hRDdeQSkmmoh9BsNhifBuHOhAQsgU=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=BtEKkBlfW2C+kqX0lsJIG8IdTLZP0bWaOdss7zCwImz5COHTqZPQ09O03D0zGIwM5uBJbJ5morE3iG45k6oM7fV2GPDxBtDTeWiOxgserMWrZ5u4W6wAJfUveLq1Ke86aI+i2KXGbWGePVIbb7U2vUl+gVqC0t650liJXE0b+y8= 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=oKCQhpiQ; arc=none smtp.client-ip=209.85.208.51 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="oKCQhpiQ" Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-69a5ecbbfb2so1427427a12.2 for ; Wed, 08 Jul 2026 08:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1783524128; x=1784128928; 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=RZIUQ8lhybvuqUO/Qu4fqmCKQSSQtg8HD8yQYy4im0M=; b=oKCQhpiQCa2dwzFjxUvNxgyJJl+dqtwc6st1Rj72vJL1ensrH1/5ilfNV0fS7AzIb4 Q2vtHCy+an+l8YC7CYjZH9uZGuVHyorH0Nc0gTwtdUX6HekGBtdxDt89JtMlk8RHc5NR epTrZiaz5VA27dJgDYr0TnOJyTApavcs6Z37XyCVCmEeRVSyETNFEa69IqazW/7+eqRr RpspogJm+uzzh8l/YMMKwhCt8l1APi3SlV1xLbTsNox6kJ+A8+bHxuY8zB7dQ9EkN0NW k5Pv4p0I2dZGM7PgsvtX+C2PAObFsBK4wUmNY2KaVr488sd/v5+I8r3xQSfnbJxNc6QK UBEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783524128; x=1784128928; 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=RZIUQ8lhybvuqUO/Qu4fqmCKQSSQtg8HD8yQYy4im0M=; b=jGMFxdDU9B7g8AwVIAe1PfEUBtTcOuJhdH8StmYySQVL2y2/5bo2ui6aw2Ae1fCFZ0 ndInKAx9+1IEXJyJmGD+HSSt4sL/g3b8VTT2pvyDI39V+bHc/EIFqllikCuhJPyz6KuG ursxVie25tedeQFU4RFsZx8PqIvBX4iKZ4xzTBCR+t9b0sz308WwuKEv5qfFuZFLJKg6 QkDlv/4P8vYKTc2O8lR/NtoheN1kyHSZwYIFla7SQfA3ywFh0kMpBrl3tUHTzK5khf6C ZWEDQuXokjzPzAYZfTb6Esq1I3hDaS8RtfJTtC2hRdJEsfih2orBZefUSfsa8yOdPA8O NTHg== X-Forwarded-Encrypted: i=1; AHgh+RryTUWaJwXI9c4msdQ7f/16i0P1L3Nbfp2tRoJgxya4Dimw05ZavMmiqSXV6CvDbS/6lDZLUgt+ZuAlZG0=@vger.kernel.org X-Gm-Message-State: AOJu0YyJE44EbWRu82uEQnvA7CTu3SxHkiJszn9rqmA5F4PQgBKDZKi6 mM3v8ruyLBLw5NxuUPECFHEuazvgNLIwhqHkqUdpHcyEK3ALA1mBPHWzb9BW55dk8PC5+7UJjKe 2bZiO9hw= X-Gm-Gg: AfdE7ckSN/XnF/Jcdnr2EfdjgGhNBOFx3ZAH1pRFyiYXGAFIP1JT2qXcB+LvF/g9nzL 21fFmUzCYI/rrCnkfWjcRb85213EbwBud4Uq1oKUq4igP8izRzZyZDpq6h9Ev6210ni5Qw5xbba tmerAb2tdNoB3uEHzJQFzVb09Ra5Ex1S3C1fBivWr0IV/Pxo1dOYWMnr4SKT2c1rQ2M6MMrNwL+ ZtYZAl2xklh51Zp3BbYS1ccwHkzfxrIPrdxIJwRfTZGNtuGcewRw0w94OBpQd4rGo3lg/kk16fQ /nh0oYJVMBEqFIUFcmP2RrSE5nOBVzMR4OCsXoqWxr73+yGL48tKqcoBco8RwO1Ki8nwIDdUQkl IkVaxHswyV9+88HS9G1ldE+yo1Js1HFheSQMmK74nsq8ezQmkCemVblWfATELXEf+lwd6CxYml0 p8iFAarpQFe2koOusydEkg1WK+YcYb1Mhns1ZJD4Kwof/Rs32J6/nO1/2PTGsq0LWIChsdceBIi HqLFlU= X-Received: by 2002:a17:906:f0d1:b0:c15:cc30:6c70 with SMTP id a640c23a62f3a-c15ce0c06damr103325566b.42.1783524128259; Wed, 08 Jul 2026 08:22:08 -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.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 08:22:07 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Wed, 08 Jul 2026 16:22:05 +0100 Subject: [PATCH v2 1/2] drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind 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-1-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 In [1], sashiko reported the following issue: =3D=3D=3D snip =3D=3D=3D Looking at how these fences are managed, drm_crtc_create_fence() creates a dma_fence without taking a reference to the drm_device or drm_crtc. Because the sync_file framework exposes this fence to userspace, the fence can outlive the CRTC. The dma_fence contract requires that data accessed by dma_fence_ops (like get_driver_name) must remain valid for an RCU grace period after the fence is signaled. However, drm_crtc_cleanup() and the subsequent freeing of the device do not wait for an RCU grace period via synchronize_rcu(). If userspace calls ioctl(SYNC_IOC_FILE_INFO) concurrently with a device hot-unplug: CPU1 (Userspace) sync_file_get_name() ops =3D rcu_dereference(fence->ops); if (!dma_fence_test_signaled_flag()) // Preempted or delayed here CPU2 (Driver Teardown) Signals the fence (setting fence->ops =3D NULL) Destroys and frees the CRTC without waiting for an RCU grace period CPU1 (Resumes) ops->get_driver_name(fence) -> drm_crtc_fence_get_driver_name() crtc =3D fence_to_crtc(fence); // Casts to the freed CRTC return crtc->dev->driver->name; // Use-after-free ... Does the CRTC or DRM device need to be kept alive for the RCU grace period, or should the fence hold a proper reference to prevent the use-after-free when get_driver_name() and get_timeline_name() access the freed CRTC structure? =3D=3D=3D snap =3D=3D=3D I believe this to be a correct observation and this patch implements the suggestion of waiting for an RCU grace period before proceeding with destruction of the drm_crtc, so that get_driver_name() and get_timeline_name() can still work. Link: https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-c03e= 77b36f34@linaro.org?part=3D1 Signed-off-by: Andr=C3=A9 Draszik --- drivers/gpu/drm/drm_crtc.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 63ead8ba6756..d55f1377ec36 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -501,6 +501,12 @@ void drm_crtc_cleanup(struct drm_crtc *crtc) { struct drm_device *dev =3D crtc->dev; =20 + /* Ensure our dma_fence_ops remain valid for an RCU grace period after + * the fence is signaled. This is necessary because our dma_fence_ops + * dereference crtc->dev. + */ + synchronize_rcu(); + /* Note that the crtc_list is considered to be static; should we * remove the drm_crtc at runtime we would have to decrement all * the indices on the drm_crtc after us in the crtc_list. --=20 2.55.0.795.g602f6c329a-goog From nobody Tue Jul 28 17:20:25 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