+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-c03e77b36f3... Signed-off-by: André Draszik andre.draszik@linaro.org
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.