From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF0951BBBFC for ; Thu, 9 Jul 2026 14:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783606758; cv=none; b=u8siuD13nb7AhPvG1xau/fzzstXfZk2PGfgjw4w4/dxtS6Rm2yWzkNwWD34+AB+3ryR1/gQtAKfRNdpR5gz4XcT53LeA6xe8SQCNVgR1BwZ0Pr9/mWSl3HAi7PUcv76oWZu7xoiGeKPCnFDebY+GsdscpojuDs8dJNMedWUnJfY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783606758; c=relaxed/simple; bh=ttNAzd6I/ZaDegdJeaYWdH1yZmzDjqnA/YL3Pm2rvsw=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=cTr/bm0MBpz9R04/caCNeEWC4msOgRgTiM6nsFVvyEGXLBotFr6trRy+4G8i1LcWbVkpVIolgmdnlRgglRMTlVSTnMcFp/TB2ATXjsrna/slAH4AX+x28CDytQv70QFvPFh33pdsrTVboS8A1Toh/jA8lflWd3m2Y7QBsIbTGSM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=Zbi2aVuo; arc=none smtp.client-ip=209.85.218.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Zbi2aVuo" Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-c15f47e6297so28499966b.0 for ; Thu, 09 Jul 2026 07:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1783606755; x=1784211555; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=mbTByd7x2B0SVAGizj79lBbxC5X4KQlpFVsjQoIekHk=; b=Zbi2aVuootiApF4z3r/c041uaLYQJXh+LT8G5UGWMPfKxdRKmtgvVUaL9JT9Tf24yW L211wYpYHLZFJ0qqGV+9Xvn3q50VqPkjKlSEa5vmJsuBvUaV2Eiqa526XEr0dwXk5gU8 So/jX6pOGVJqY0Q75TjC0xYfwbRsLoDjGzxNNnRmq+/iM+vNlEF7L34/cOoPZ0PQRTPd FkadwZMnHKwhT0PcW3+mgpRPEMkncQOEbY+SlF+gISrSwwwvkO/R40SH1hftO2pXjJGh vuTVNNzLfbExeXj5Nv0gZXv7b4UGHGGPgYTddMH3TgMEb4k95O80bCKvAk+5n3LO83eo qE0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783606755; x=1784211555; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=mbTByd7x2B0SVAGizj79lBbxC5X4KQlpFVsjQoIekHk=; b=dEXYDZ1YKCVxpA0NdviVvauoe/60kYUlRuADGLD9p/p35i/jL2aS54PvCYk5sVakaJ 16NJhTEuf8mE1t9j4vVqDOOI0BSf2eGHTL7U07l7VcLZl12BFluiOytLb8BXhAqhafSG ojyDdQWxwPFGA7GD1seisEl3ha3mj9AcAkCqLHo6ekXZP5Dwqquv9p8OXVF97+2tCG4G PVVPvQCvj1zi3GC8QGf04lkzgmfcvMgKC1b36eTEOC3CFjVby1E4joSp652dre2w7TwH s4lkQWPDyL6tvKV/bF0/H77fJap7S7RXb4GUy914uCNXSRTOKp4SHXpBhYSy3u16ybzR PyBw== X-Forwarded-Encrypted: i=1; AHgh+RozFWH3A+WmJqcTHSDKt6d8YTB2+7z1VNI84M/WDC8f6yBGQYP/A0pfm4+fCF6PQxM5VgWE0IoPsLklLpU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyy/2xaEDHy1im9RZEKmp7BgHklmolavaPFGR9u9yERPT1ii4n6 TT+Yv9CmeRm+Qb0T/Eh3f7uQBMpzhlxuiR1ofmiuXw2ax3X76VHW6Pk9bltn1W6Dq5k= X-Gm-Gg: AfdE7cmSUumkraJI6xoVXrSubO6OLUowV8loeYdys0AVqNX48Lofq5yb+Xs5hh3Azz4 IogU35xfUKplmv0IobsXcOapNReojUzqoGkvGTb2q2ncixO8veClgBrQlI9fPz0TJa6KEGXVh5O ydVe9/r/zVv2RfrPFdiWqeOhDTMZqmaBVlI/BIt/qVWhUCS9fh0+NoE02S5MxhPRhz7TI/QdCt0 WJJ1HgapAaqzzuzEz3mi7nhyEW983qr8wtRUbmqetcT6/K57U0dOCDJC0zJysbBQ+fubxtbKs+r ozX67SfJPsuAmSPaUDrSCX51ALVCVZavkl2X5vl0Bdpvo/izdSO6BpuoxJUdC1UWSNqPKUBs97w UWzH6Ct1/Gee6GW08RpOEb6V0Wciq3Vauhds/utqB/gj2LG9pSMfU5/c003sIqWJZ2/ofFHw41u RMEat8gb6OA/vPJiDvVW5q X-Received: by 2002:a17:907:e146:b0:c15:b55b:7826 with SMTP id a640c23a62f3a-c15ce0c03f0mr176642766b.39.1783606755075; Thu, 09 Jul 2026 07:19:15 -0700 (PDT) Received: from [10.1.1.102] ([212.129.81.133]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c15ae0bb618sm497210466b.20.2026.07.09.07.19.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2026 07:19:14 -0700 (PDT) Message-ID: <899942cc84af7a82a35b4ca34b486c40327fd543.camel@linaro.org> Subject: Re: [PATCH v2 1/2] drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind From: =?ISO-8859-1?Q?Andr=E9?= Draszik To: phasta@kernel.org, Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , Christian =?ISO-8859-1?Q?K=F6nig?= , Tvrtko Ursulin , Boris Brezillon , Danilo Krummrich Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Peter Griffin , Tudor Ambarus , Juan Yescas , kernel-team@android.com Date: Thu, 09 Jul 2026 15:19:30 +0100 In-Reply-To: <1ccfc0b5d1696a8dec4756b675294e7fb41ab5ff.camel@mailbox.org> References: <20260708-linux-drm_crtc_fix2-v2-0-cf72be75d75a@linaro.org> <20260708-linux-drm_crtc_fix2-v2-1-cf72be75d75a@linaro.org> <1ccfc0b5d1696a8dec4756b675294e7fb41ab5ff.camel@mailbox.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-8+build1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 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) >=20 > On Wed, 2026-07-08 at 16:22 +0100, Andr=C3=A9 Draszik wrote: > >=20 >=20 > [=E2=80=A6] >=20 > > Link: https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-= c03e77b36f34@linaro.org?part=3D1 > > Signed-off-by: Andr=C3=A9 Draszik >=20 > 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 reasonab= le commit to relate to. >=20 > > --- > > =C2=A0drivers/gpu/drm/drm_crtc.c | 6 ++++++ > > =C2=A01 file changed, 6 insertions(+) > >=20 > > 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) > > =C2=A0{ > > =C2=A0 struct drm_device *dev =3D crtc->dev; > > =C2=A0 > > + /* Ensure our dma_fence_ops remain valid for an RCU grace period afte= r > > + * the fence is signaled. This is necessary because our dma_fence_ops > > + * dereference crtc->dev. > > + */ > > + synchronize_rcu(); >=20 > 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-c03e77b36f= 34@linaro.org?part=3D1 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'