From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) (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 6FF4740629F for ; Mon, 20 Jul 2026 12:04:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784549079; cv=none; b=pOaA7QEoqEldUDidYJQM5Oz390C7g8wXy/jRENgwbEoLXKVhhMwJFMs3TLJ4oKhJaiNytRH6fvRD8dCWO00U3xBXpnYXVQp4HMWx5WdTcDrb96rgiAfN4MYpoyi9d5lBua9JGmrXcN/KxjlUWhyinfO+ZLdZrBAQ8UdKsAujXbo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784549079; c=relaxed/simple; bh=4ATboiu3c5KqTH0slwsg9MiwpKOYlAoPTTY7ipBfLRY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=s1/Y21c7cjB5yRFA3PhMUlwyvjGTVMud3zCmYsR3XCoEVQ9X+oexk7jVACQFSIAjfkFoLRVtqwaj0b14T09/WqwPbzrsOBml4GjsZ96Q5Vn18fFx6u1C2qxl9W3WNRRXuKUKvMbYbA6NhjB8Q/6WeK6NmWu04hRIubyQD4DBdvw= 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=rNeG4C2B; arc=none smtp.client-ip=209.85.218.42 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="rNeG4C2B" Received: by mail-ej1-f42.google.com with SMTP id a640c23a62f3a-c197f968b3cso78401566b.2 for ; Mon, 20 Jul 2026 05:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1784549077; x=1785153877; 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=4ATboiu3c5KqTH0slwsg9MiwpKOYlAoPTTY7ipBfLRY=; b=rNeG4C2BYr+5q9GXOf3vT1JDslXkyc2rfG0zyrFfYrrOdtzBhPCudlXhvlFYFGp5mh XrLI4rmnhEJ/60GLCmRPwHt6NFfOPHpFb1ZTtoahW7al/Q2xaWORl6EC2sN42wiiIwe+ 9AruIN3I6P5VI/llYoVkIWmQUUifKZbbEd2vy+hDcH0VYNSF5mK4LJhe+rrAGK6YC55e stdKbb44rQfTk4LIENvUiZFRJOxhlNZoySb9vQ+ALS3F47phQDefLSf2xGz+zCVqF3Bf 9QKJSTY+b5PImMsqcTGv7Sf2cuh6v/nLbqxhwYXrtWsEs1TOkgWNsiIQjSKF2p5w6rL8 P3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784549077; x=1785153877; 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=4ATboiu3c5KqTH0slwsg9MiwpKOYlAoPTTY7ipBfLRY=; b=I8OtS7KP6Li3VOqxNNcBpyRX7KrD7mlagfOF4FHv2pN995Oz/xsJ0vKkcUkw8lggkw lvIhfaiZ8ZbKfd5KBlKzuBVnj4WYcjCsyZsv1d1ZGtIIDfWzxYLaFJ0fLEy9ikKjrbpN lTbKStxnhOU9tZP0wQwlpfE2tqvnmd1Z1bafQ39XpqNIBYi9LKI1ux/qISv5Z1t5NuCa RQn1T+gBIQgADhSz8Ev9KRlxaq+lAUGJfxQU4sdOmqYmbMCfLUA3QYdcqSfHy9gJWF3Z a3UYCYvxXztvqhHv1M6NHKXFUQohv+omNXt2m6dpiNJE50abx+8rY7wfFRRBq/WQDqAA FtoA== X-Forwarded-Encrypted: i=1; AHgh+RpyhfkSWkCrpWxeDR15GA8hxjMtp2aDAnQ9jHhEuVURCV98BNj8rCukHGzEwW98EQT6wlpew1YghNUMwFs=@vger.kernel.org X-Gm-Message-State: AOJu0YyOw7WtxeUa4QahQ5foJyz6eHA83aUpEdaHi0/MKc9fx8qTN2VB hLP+0VTVwz+UgaTpREadM2N9vgJr2eDCThAy77fOVJ3aYW2sd0I34NsOCxSWl3W38EY= X-Gm-Gg: AfdE7cn5iQXYPjFVeFS8NrApHew99qbuYCwmyjLqdg9um87b4TOY4/fBfR4uQ/YpCal P4blbpY4iPHepQGhRgUwc3KTb49cLZbgdll0Crmhi1luruluyRiRUd9vJxrk0OeU7JxjP7ZNYYA Ne7l9G57rj5s6jxwKTGCChQtU+4g46WMdD9batyHR5uALqdamuq95TC9yslPNNWKQjh+HBonvbF 6VyyIkHhJX8c5M1qEhfPpEK21c3uCprDzDbK/KUBLkdjm6hPXQeKfQgNDu2oe3gT+UivHXYfiv2 JBrsJHJnC3rMDU76bsTaN1C1UM/ev7bKqRgSDR1avJ4zsfSmeHRRaCdyE1okkcqBdeaHXui/Epl Ljy09i1YQL3lD7m+RIqAqX+rnGG4oDfONaKJ97xtslu7r+zNWbvX9+rt6qlG7goyrJemfE13FNE J5nTgVkA== X-Received: by 2002:a17:907:d508:b0:c15:f4e0:72a7 with SMTP id a640c23a62f3a-c16b4732c58mr541282766b.39.1784549076676; Mon, 20 Jul 2026 05:04:36 -0700 (PDT) Received: from draszik.lan ([109.255.181.4]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c17009ae10fsm458630066b.10.2026.07.20.05.04.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 05:04:36 -0700 (PDT) Message-ID: 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: Mon, 20 Jul 2026 13:04:43 +0100 In-Reply-To: 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> <899942cc84af7a82a35b4ca34b486c40327fd543.camel@linaro.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, (sorry for the slow reply). On Thu, 2026-07-09 at 16:40 +0200, Philipp Stanner wrote: > On Thu, 2026-07-09 at 15:19 +0100, Andr=C3=A9 Draszik wrote: > > Hi Philipp, > >=20 > > On Thu, 2026-07-09 at 14:32 +0200, Philipp Stanner wrote: > > >=20 > > > On Wed, 2026-07-08 at 16:22 +0100, Andr=C3=A9 Draszik wrote: > > >=20 > >=20 [...] > > >=20 > The issue here seems to be that=20 > a) the crtc is made invalid in drm_crtc_cleanup() (memset(0)) > b) the drm_dev can disappear after drm_crtc_cleanup() >=20 > Both issues stem from the fact that the fence callbacks can keep > running into the driver. >=20 > It is true that the fence, being refcounted, can stay alive, but none > of the callbacks be invoked anymore, and your grace period wait > fullfill. >=20 > It is a strict dma_fence requirement that a fence issuer / producer > signals all its fences before unload. OK, I missed that. In that case, the patch should indeed be fine as-is. I'll just do the (minor) updates as you had requested. Thanks Philipp