From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 A4031329C6D for ; Mon, 20 Apr 2026 16:19:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776701949; cv=none; b=pf7INnmg+ejfUPNwAxgwVnVoukeetGJ2Ca9ZzN2o7R5pITwYv+cTubR61fHQkF8oj9xxLqEjQircCmM8CzznCfN1DrRticjIsVawKg2D0QmZ6d7BbINsnkF5M3M+jQw4yB0+mjfvTYfh6Pj1D6nRU8dtB6gfNftDc4PXAlwfeF8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776701949; c=relaxed/simple; bh=9WCaWT1uDDnVbHnYE/bKi6RTzJIo5ibhmjljjeuufuY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=U7iGx/rks9CPUzryoultV2EdH5NScMyFdgzHhCoMgTcLYoq5TWVoKzvJfC+EWrUdYkZZedvxPeGfLDEJS2dVf9Pn3p7FFtVNG6/XcLythMWgsoYzrWtEHavlvbtVR5fKeqmPBruHXt5Vh+dQIX9Hw5EoAOzwvdS+yom6+9UR+hM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=P8KADZI1; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="P8KADZI1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776701948; x=1808237948; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=9WCaWT1uDDnVbHnYE/bKi6RTzJIo5ibhmjljjeuufuY=; b=P8KADZI10l0UNzthls9LPvZaHi9KV9aWOuAgNxtes19kh3l+0ky50WoU Ux/62Zs3IP4Q2yxtC1XM3l8J6HpVAskf64BifNj2Puhvj5s6Z+YjRoQul VWveYoVBx5meA4src7K3jY3YNUVW+KdI1cDGr3pTyMD47VGxosi+Aq2+w 55dpssn+q6H+lENOl/D92dY/IHk78/DEpqBYg68HMeb4kvl0wmz7KmDp6 Lc73AtYMi4Jjw2kFKeUYMu64cWKJgSuva8fmBixDk9MbR2fptDaZIAKbV A4SaG/7UM15vljVIVmh+URR7yChrbviWC7EXmsFrpJh+uyR4KLvQ0NjsX Q==; X-CSE-ConnectionGUID: BXhcdZsrQXSqTTFWApOwnA== X-CSE-MsgGUID: X22WOryhS120rdEEdohFAg== X-IronPort-AV: E=McAfee;i="6800,10657,11762"; a="103086201" X-IronPort-AV: E=Sophos;i="6.23,190,1770624000"; d="scan'208";a="103086201" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 09:19:07 -0700 X-CSE-ConnectionGUID: tUbecKS0R8GanHV116mIPg== X-CSE-MsgGUID: McHq/mSiS9+07DjgwDZ2eA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,190,1770624000"; d="scan'208";a="225272466" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO [10.245.244.133]) ([10.245.244.133]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 09:19:05 -0700 Message-ID: Subject: Re: [PATCH] drm/gpuvm: take refcount on DRM device From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Danilo Krummrich Cc: Alice Ryhl , Matthew Brost , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Date: Mon, 20 Apr 2026 18:19:02 +0200 In-Reply-To: References: <20260416-gpuvm-drm-dev-get-v1-1-f3bc06571e73@google.com> <544c97fe296f39da35e5349ba1fc0af05f2ff643.camel@linux.intel.com> <215f305ff04ddf8a426871e895aaf520b02e89bf.camel@linux.intel.com> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-04-20 at 17:08 +0200, Danilo Krummrich wrote: > 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. >=20 > 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(). >=20 > Besides that, if GPUVM holds the module reference count on behalf of > the DRM > device, it has the same effect that you rightfully point out below -- > it breaks > rmmod. >=20 > > 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. > >=20 > > https://patchwork.freedesktop.org/patch/712146/?series=3D163298&rev=3D1 >=20 > This looks like a reasonable fix to me. And it makes me conclude that > we > basically agree on everything. :) Yes, unless we'd want to do a similar wait for gpuvms before returning from the close() callback: If we assume all GPUVMs are tied to an open drm file, that would conceptually be nicer IMO but I agree if gpuvm drivers implement something like the above per-driver device count, that would be unnecessary. Thanks, Thomas >=20 > 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. >=20 > > 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.