From nobody Sat Jul 25 01:25:46 2026 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (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 4646E3BA237 for ; Tue, 21 Jul 2026 08:21:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784622095; cv=none; b=TBCp9zs7NXDIelOJkIX85rGcevxBjOGF3zeg73ko5xYJp7ZwD4PDqGbHEkX9sykN11iNxIRP5GhlnbmEKYuyTb1kiCMNkAaIxq19U938TT6ELStZ+BBJpDWz3+zfV6qNuwouIxmtwpfqZHUnzklGVhvK7MhWLYqUJzLwVNRYoTs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784622095; c=relaxed/simple; bh=CGfct8PUQ7k/GTBXx1thDEW1+DW1UM9fabzaCE228PE=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=N2modKR8+DW6tNQRzToeGraFYz71V3Ftr1NnI9Q/Vnjg6luI79Dz+LyJoPxfOXiqwQb2zYPWYpFFW8nSTcXxSpsza/qAZD7//mAclZMIqZLhZhb3W9G3hgmzJ3dD0MZJt641aVVrLSrJSi6AImzFlcYqGviC1JvCXxEm3MnXFR8= 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=mGRRCqoT; arc=none smtp.client-ip=209.85.208.44 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="mGRRCqoT" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-698a9f11776so12645742a12.1 for ; Tue, 21 Jul 2026 01:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784622091; x=1785226891; 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=WvkB7fQj9FMYGIgyusU+WdEm+X4LQCuorVOln1T7cnc=; b=mGRRCqoT6rITFCEGolRkfCisPHmSUO4BTmxMZMohCQcLXdESMzFrDmnP9X9box/H56 QXde8n4M/JawrLghEmO9TRtx+pjj0Tt3+bi7cjsb2lnSy2LXj6cKZx0M348S8TY4n+V4 Jyn5yvQCTlTxYX8ofY174NKqu5qS2+KbPUSGiyboZr1bp5Mzb/JCu8P6tsLFHdEVLQ0P V5n2czkAUET54ezsQUPnhRlfUeoIBefuuIe6w+9LyvWkKzJuvv8f1Fc733PlRlpbOcvG i9hJC/Bp3Jt5QbWMmrc0sYbSbCoUvf9GDgS9ftrEo+MBTHrS1K3Ogg2adUAZnRliULOl 9I3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784622091; x=1785226891; 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=WvkB7fQj9FMYGIgyusU+WdEm+X4LQCuorVOln1T7cnc=; b=GVi0cbBprAZKq9OPmsr546XdJ8qUdf3S5bjU6q2LtPtIB5SpcAY5zQWKVAu0cQNTdU 5ZJ+WV7HEj2F0ZLgjwLfI1Tg6QyGCvegb0ztuSOdERM+lT9OormPzaRqeKXUhqfXsc8d acLaqVsPUKhxmCMdCgzmnN5/RuCvgPdwkpk0lMmJ3KRFFlHLSdUA0/dLDs1qxdlxsVGi 2bFkKNdjFQqVUXuLkoXLTDsuu1MLmmvwX+0aGclFfLYe18qY7EEp/De9ugq+9tgKcGAM PUZ+FlslRgEe83qrlv3tucUFNpCywoyMncRXD5R2WWQI9vdQVQEg5/byg0dbJV34Qf9+ /4aQ== X-Forwarded-Encrypted: i=1; AHgh+RpZTIP/5aLmQAEm55VLBxI9zvprCXsXVZspuSB9Ai01o9VcFY4n5cIKKjT2s3XRtRhdzE/V9Es6fmJSh5M=@vger.kernel.org X-Gm-Message-State: AOJu0YwWe3SvZtnFcpc9e71H5nnM86Vra6iRkE+To42QuO3hf8zbku38 LhubOc4EFF3deN0cWElYDRHjMjf3zdWTmvFQgqXaxWBCcbc9p37lanyKtDbBjcw+ZDI= X-Gm-Gg: AfdE7clmJz3dnDmUEgNuLmWoZRgYLB6utbS6TyyZa3412gjbuAXhpYWbIKPNxwcZMOa DqHqiRddkNYGHblpd5gYNFkSgTn2MHaN/qbN3rWZFUV0UUBc8loIFJX89zFtPyqLqTC4grQT4Dh IEc8fAvcoOM6s/39DvX4KpQJ66A9PYoSDMdhAj+t6JzHVOpLTJ7td+kurQRwmQyyJrbW/lJkuHh 6cRJadTMowWpFZ/QfNibvc4D5cgRXz5QfQ4biL1jGVSKacSFTRDRmSSIQ4EdpXi6N4lchl7SE8U 0TFZ31wvpY9aKZmzVjAOGJrh1JikMLHz4d6bmOwXVBtXN2nXboDzw3GdW0A1tbxzQ6YQTyaS2qs n24g08ZqVky2UosfSNTRh/TIrY5/82cwucULFUX9wVyp+kWSkf/aFS5DKapcm2oGBJChFFlanO8 giJKoyoRkgDdYOGHo/hTuJPCiDqyAtXQEXkfB3aZUjBZcMq5qH+jgNS1lniYGGwGa20g== X-Received: by 2002:a17:906:ef08:b0:c16:7414:4c29 with SMTP id a640c23a62f3a-c16b473acc7mr947501366b.25.1784622091388; Tue, 21 Jul 2026 01:21:31 -0700 (PDT) Received: from puffmais2.c.googlers.com (185.155.90.34.bc.googleusercontent.com. [34.90.155.185]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1724f50b72sm564725066b.48.2026.07.21.01.21.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 01:21:30 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Tue, 21 Jul 2026 09:21:26 +0100 Subject: [PATCH v3 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: <20260721-linux-drm_crtc_fix2-v3-1-afa8c71506e6@linaro.org> References: <20260721-linux-drm_crtc_fix2-v3-0-afa8c71506e6@linaro.org> In-Reply-To: <20260721-linux-drm_crtc_fix2-v3-0-afa8c71506e6@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 , Danilo Krummrich , Sean Paul , Gustavo Padovan 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, Simona Vetter , =?utf-8?q?Andr=C3=A9_Draszik?= , stable@vger.kernel.org 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 Fixes: 6d6003c4b613 ("drm/fence: add fence timeline to drm_crtc") Cc: stable@vger.kernel.org Signed-off-by: Andr=C3=A9 Draszik Reviewed-by: Philipp Stanner --- v3: - Philipp: update kerneldoc, add Fixes: v2: new patch --- drivers/gpu/drm/drm_crtc.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 63ead8ba6756..e8e80c936852 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -493,14 +493,23 @@ EXPORT_SYMBOL(__drmm_crtc_alloc_with_planes); * drm_crtc_cleanup - Clean up the core crtc usage * @crtc: CRTC to cleanup * - * This function cleans up @crtc and removes it from the DRM mode setting - * core. Note that the function does *not* free the crtc structure itself, - * this is the responsibility of the caller. + * This function cleans up @crtc and removes it from the DRM mode setting = core, + * after first waiting an RCU grace period to ensure @crtc->dev can safely= be + * dereferenced by our dma_fence_ops. + * + * Note that the function does *not* free the crtc structure itself, this = is the + * responsibility of the caller. */ 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.229.g6434b31f56-goog From nobody Sat Jul 25 01:25:46 2026 Received: from mail-ej1-f51.google.com (mail-ej1-f51.google.com [209.85.218.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 0AD24443A9B for ; Tue, 21 Jul 2026 08:21:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784622095; cv=none; b=k53+SfColrPbIFVCBseWR2FFGGd3jHJYSpAwNsqSe3S2jGqShIP38oTkZ6s90ljRb5tnfeibGoBUL46U4RcAJvBNgVWBfx2RsSnku289S7jRyh7UGZeOYmNGPBMmq0xRWG+m1xdFwhoVf+WqgW9ZKZpID/LBlg97U0uyVCe/lh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784622095; c=relaxed/simple; bh=ctu2JAjDb4vEv2Ofqw5ZSiuq7IdmtEWY9UJl9tqds/g=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=M1HdeLFCpwrS1mCw+yENGxDlNzUhoCEJOsBmnaqDerP2ePJ6yAtD5SAyA60mBHql1dhYIujuqCCRAIPE/0pTf43K2OccpYF+HBaF5tA776IpkrgYkjzrxTN7nHMsRidADRy59DLE2GFDmuWxuNaYa7dRmY7EEfXYEa8V6z4p+To= 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=kyt04m/P; arc=none smtp.client-ip=209.85.218.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="kyt04m/P" Received: by mail-ej1-f51.google.com with SMTP id a640c23a62f3a-c15b1da6b82so821444566b.1 for ; Tue, 21 Jul 2026 01:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784622092; x=1785226892; 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=yOwKc54gLFklrg6TasEGy36BkhC9F73PBQa2PoKh7F4=; b=kyt04m/P2r5oxEC7ywbWuP+tmSyEzFkvUV4fMlHCNbYNb3aTEbUQv1kqASeYNC7dna IOnCzpSojBAZmUw9/E2NyK8rtUjW2Y3KOoHJ0ijDBeebq6OIioBCzOr4gikWeyyUDggQ Yy4QJ7WZ0fitLw27yTQv8sJXKsi60zpDAIY664OzPPb58JWLojqSXrNKl2sUyFQyJ0d/ IpF5qOaAHm15UraZee/UkvRiTeM4eZbRe6iVi6TUGrglPuicP8EkK387LJ3hZVeL7sfh Fmd8V1RF5NstAAK9428gdb1lO2WwJp8CkE+BfaIBQoKGjloYrwd1Phf0h0n/TujIZQM5 UKiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784622092; x=1785226892; 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=yOwKc54gLFklrg6TasEGy36BkhC9F73PBQa2PoKh7F4=; b=GVwjSaPDyLdbKkDjWq0FXa/SAkj0XBodAQ8Tb7Ixtd+mtrZQjuMWm2Is2898AqLf3s 4dcpq68ewKCWu/JPQ/vDh8nDBuc2iEeD2s/ltKSK0U2D6MJmCPzbdxAscsN5LzMSddMI rty4RHMp2peKzqzpdQ+Kz2drHhdu7XeLpcnCv28zDdHVqfTHzQl5ZixBZrRxxJz7ur6N 7NcvMPGi3deLQmLLXk9Rm5EDNwzgBNQ/YNGi5NHPx22nOv5Ph9Lf7cUUnT8V2c6s5UKY 6wqXqFRX27gBs8fFetmwYT7DLlwkUC7vxRX+jP0hCLTRlo3C756xefHs8fTL5W5MkXN1 5Xlg== X-Forwarded-Encrypted: i=1; AHgh+RoedRERTJY8yU0bQ9fIoutJuF8JWnj7o+ZncOyRgRLApCOswOatqkr/Okwq71w3uDLxw7aJ0vvpG9nRahY=@vger.kernel.org X-Gm-Message-State: AOJu0YzrsfW4+ST4HpNLgZUg4dry9ZDXP5tlMMxvEF7XoUubCet0sHZD JBGTwLMhq8yV/uxQ+Fmq9GJHKwUvp9aguWVTS8s7Tzi5oGWfKDQkx66PkKk3CkGJ9a8= X-Gm-Gg: AfdE7cl8Fbny+Bg75yc07ztf65GcILenXEd+jamll/BxQRWI5BGb6vac2RMqFHrUwjH l2wxh80RSD8jFS20K0MyYNHN+uNVMOIHnr1ButqF3ZgvNOCTsoFft8V27/XSp2CwSxIpc1bqNJ0 xMIhBFD7maRZEXKh7Sr+qW1cy4+ZbTPn/h4o+k8RjpltqdXiPWaZnuQZg9YosjJTj5Eda1IDaG/ U9PE6yKFEaf1+exILWurTUOaPuPNv8qXIhX1PIH8sMrCZ7pP/dFZsyA4mrSnWOLGfSG+3rEbb4l ENnGnmpRplO1eyie99wHxHAk5Y7YtiW4Iuo4HM7uP7dL88aImoqMtATpxuCOavJVkQIhyXqzwYm Nser5Meoxmio4JML+q+XyJSlohHwG4CMJHYKBB7891W5vHeaUNt/Li+UDh3SQlrweS06Yl0IHJW bXdjASamvrsCQ2ONK4761cmsApz7wJgLafaha9Nu1is3xvyKiEka9uYnfpOy90YXwFEg== X-Received: by 2002:a17:907:c5c5:b0:c12:f81:661f with SMTP id a640c23a62f3a-c16b4833e24mr638733366b.51.1784622092166; Tue, 21 Jul 2026 01:21:32 -0700 (PDT) Received: from puffmais2.c.googlers.com (185.155.90.34.bc.googleusercontent.com. [34.90.155.185]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c1724f50b72sm564725066b.48.2026.07.21.01.21.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jul 2026 01:21:31 -0700 (PDT) From: =?utf-8?q?Andr=C3=A9_Draszik?= Date: Tue, 21 Jul 2026 09:21:27 +0100 Subject: [PATCH v3 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: <20260721-linux-drm_crtc_fix2-v3-2-afa8c71506e6@linaro.org> References: <20260721-linux-drm_crtc_fix2-v3-0-afa8c71506e6@linaro.org> In-Reply-To: <20260721-linux-drm_crtc_fix2-v3-0-afa8c71506e6@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 , Danilo Krummrich , Sean Paul , Gustavo Padovan 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, Simona Vetter , =?utf-8?q?Andr=C3=A9_Draszik?= , stable@vger.kernel.org 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 +++ In other words, a fence's ops pointer can now change to NULL on signal, which wasn't the case before the culprit commit and hence the BUG_ON() triggers. Simply drop the BUG_ON() as it's usage of fence ops is invalid now, and because using BUG_ON() and friends to take down the system is an unacceptable way to handle a failure. 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") Cc: stable@vger.kernel.org Reviewed-by: Philipp Stanner Signed-off-by: Andr=C3=A9 Draszik --- v3: - Philipp: - shorten commit message - explicitly Cc: stable - collect tag 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 e8e80c936852..5295ec122e0d 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.229.g6434b31f56-goog