From: "Danilo Krummrich" <dakr@kernel.org>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
<dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/gpuvm: take refcount on DRM device
Date: Mon, 20 Apr 2026 17:08:15 +0200 [thread overview]
Message-ID: <DHY2RPB300R2.1XXG87NPYFRCI@kernel.org> (raw)
In-Reply-To: <215f305ff04ddf8a426871e895aaf520b02e89bf.camel@linux.intel.com>
On Mon Apr 20, 2026 at 11:28 AM CEST, Thomas Hellström 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 DRM
device, it has the same effect that you rightfully point out below -- it breaks
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=163298&rev=1
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.
next prev parent reply other threads:[~2026-04-20 15:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 13:10 [PATCH] drm/gpuvm: take refcount on DRM device Alice Ryhl
2026-04-16 15:26 ` Danilo Krummrich
2026-04-17 14:41 ` Thomas Hellström
2026-04-17 19:33 ` Danilo Krummrich
2026-04-20 9:28 ` Thomas Hellström
2026-04-20 15:08 ` Danilo Krummrich [this message]
2026-04-20 16:19 ` Thomas Hellström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHY2RPB300R2.1XXG87NPYFRCI@kernel.org \
--to=dakr@kernel.org \
--cc=aliceryhl@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox