Hi Philipp,
On Thu, 2026-07-09 at 14:32 +0200, Philipp Stanner wrote:
+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.
Good point, thanks. I forgot to add this in and will try to find a reasonable commit to relate to.
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.
Unfortunately, this still looks like an incomplete fix - https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f3...
My next version will simply copy the relevant strings into a custom
struct drm_crtc_fence { struct dma_fence base; char driver_name[32]; char timeline_name[32]; };
or similar as part of drm_crtc_create_fence() and just use those as part of the dma_fence_ops. That approach should avoid all race conditions and corner cases with RCU.
I'll also make sure to update relevant documentation.
Cheers, Andre'