From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 890E93630B9 for ; Mon, 20 Apr 2026 15:08:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776697698; cv=none; b=pPkvjYOt1Ue4ZB3n0Cr2EAIs9e8yH4Uvu1wQ62UeupGbkGfLV96TaonkJ0M/OTWxWGCt2egyF5sxR5XK0cayBe6sDWXyepxh+K9HofZjLTkQH2anxlRqPKthUYxNyIdQ6yIeQZghP5RQRa4+iy36h5XlyOPEpzkcrgCHPUMr/gk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776697698; c=relaxed/simple; bh=Lm07FRYIKpA8U6ZJrO9wQ8KmSm2Q2i2gtVveDLehFiM=; h=Mime-Version:Content-Type:Date:Message-Id:To:From:Subject:Cc: References:In-Reply-To; b=A8NKz+NK2RBrUHwn/oUytoWMjiDIrPoKpOtMXOM0CbKpIoZlSsn24RFUkBMbcCxHJ8lUEOI7BT/1k997676vCj33K7rs/swS/veH+BKnPyEygzNGnoLF45wfViMqBwqSRf2+KQcCRkXDmzQhLe2JaHzbGAWKn6C/wRL4/HbK54k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mGEuyqDW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mGEuyqDW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2223C19425; Mon, 20 Apr 2026 15:08:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776697698; bh=Lm07FRYIKpA8U6ZJrO9wQ8KmSm2Q2i2gtVveDLehFiM=; h=Date:To:From:Subject:Cc:References:In-Reply-To:From; b=mGEuyqDWjiHHC23jeDEmZ5Nkuft1cLcQDZ7YMWQ7dVJ8ue2+v85tWXbw+FKorMx0q HJyo8lD54osLtE2j9K/SUH54XbPmje4/dSD/WtyCcdr1EaoedwzjwFc6vbuqy8M9zu O2GjA/iW+qqp8Xddj9SyZYfa8XZk0M8Z6IBP1l5NXloHDGY9YfPrBiwGrUDp5NI+rt uqSaN4oPht0t0GAWmtNWwq2ti8mRrIFXygHnPJ6T8o7RKn+96EvN2uWjMiBr7oSpBp 7JL0uRS12qKwxz8SDhwu7mz/kkcdMzvHRuHTBz/+IzjdVPTT7gL+oyTLxr5O5nq2nr dATHCIeKzj1xw== Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 Apr 2026 17:08:15 +0200 Message-Id: To: =?utf-8?q?Thomas_Hellstr=C3=B6m?= From: "Danilo Krummrich" Subject: Re: [PATCH] drm/gpuvm: take refcount on DRM device Cc: "Alice Ryhl" , "Matthew Brost" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , , References: <20260416-gpuvm-drm-dev-get-v1-1-f3bc06571e73@google.com> <544c97fe296f39da35e5349ba1fc0af05f2ff643.camel@linux.intel.com> <215f305ff04ddf8a426871e895aaf520b02e89bf.camel@linux.intel.com> In-Reply-To: <215f305ff04ddf8a426871e895aaf520b02e89bf.camel@linux.intel.com> On Mon Apr 20, 2026 at 11:28 AM CEST, Thomas Hellstr=C3=B6m wrote: > I agree with your reasoning here, but current fact is that most (if not > all) holders of a drm device reference (files, pagemaps, dma-bufs) > currently also hold a module reference to protect against this, and > drm_gpuvm would be an outlier. I'm not convinced; if the DRM device has the requirement to not outlive the module it is associated with, then the DRM device code has to take care of = this requirement, and not every caller of drm_dev_get(). Besides that, if GPUVM holds the module reference count on behalf of the DR= M device, it has the same effect that you rightfully point out below -- it br= eaks rmmod. > To fix this properly (lifting that requirement) one could introduce a > drm device count in the module and have the module exit function wait > for it to become zero, *and* that the code that did the last decrement > finished executing. > > https://patchwork.freedesktop.org/patch/712146/?series=3D163298&rev=3D1 This looks like a reasonable fix to me. And it makes me conclude that we basically agree on everything. :) Regarding the reference count in the meantime, it remains that omitting it = does not solve the underlying problem, i.e. I still think it is orthogonal. > Or one could also have the drm device hold a reference count on the > driver module, but that would block unloading without previous unbind > which is not typical driver behaviour and would likely be seen as a > regression.