Re: [PATCH v2 1/2] drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind

[Philipp Stanner]

+Cc Danilo (who is currently concerned with drm_device life times)

On Wed, 2026-07-08 at 16:22 +0100, André Draszik wrote:
> 

[…]

> Link: https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@xxxxxxxxxx?part=1
> Signed-off-by: André Draszik <andre.draszik@xxxxxxxxxx>

I am tempted to think that this also needs a Fixes and needs to be
backported into stable kernels, doesn't it? Especially if the BUG_ON
disappears in stable kernels.

> ---
>  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 = crtc->dev;
>  
> +	/* 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();

nit:
I guess this is the only place where one can reasonably put the
synchronize_rcu(). But I would hint at the RCU delay in the function's
docu.

> +
>  	/* 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.