+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/[email protected]?part=1 > Signed-off-by: André Draszik <[email protected]> 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.
