From: Alice Ryhl <aliceryhl@google.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Cc: Danilo Krummrich <dakr@kernel.org>,
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, 27 Apr 2026 07:34:04 +0000 [thread overview]
Message-ID: <ae8RbMocX2KBivpE@google.com> (raw)
In-Reply-To: <c9ce94ae6c7956d63ca51f6e979100ec713f68f2.camel@linux.intel.com>
On Mon, Apr 20, 2026 at 06:19:02PM +0200, Thomas Hellström wrote:
> On Mon, 2026-04-20 at 17:08 +0200, Danilo Krummrich wrote:
> > 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. :)
>
> 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.
Just to confirm, it sounds like no changes to my patch are required
here?
Alice
next prev parent reply other threads:[~2026-04-27 7:34 UTC|newest]
Thread overview: 10+ 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
2026-04-20 16:19 ` Thomas Hellström
2026-04-27 7:34 ` Alice Ryhl [this message]
2026-04-27 11:44 ` Thomas Hellström
2026-05-05 11:06 ` Danilo Krummrich
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=ae8RbMocX2KBivpE@google.com \
--to=aliceryhl@google.com \
--cc=dakr@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.