On Tue, 2026-07-21 at 09:21 +0100, André Draszik wrote:
>
[…]
>
>
> ---
> 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 = 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();
> +
> /* 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.
Seems we forgot [1] this patch. Sorry about that.
This fix also looks fine to me (for now) since it's what the dma_fence
contract currently demands.
I'm a bit nervous about a synchronize_rcu() being in every cleanup
path, but I suspect it's the most reasonable thing to do now.
Let's wait a day or two to see if anyone has fundamental objections.
Could someone with some CRTC knowledge give it an R-b? Otherwise I'd
push it this week.
Regards,
Philipp
[1]
https://lore.kernel.org/dri-devel/[email protected]/T/#thttps://lore.kernel.org/dri-devel/[email protected]/T/#t
