From: "Christian König" <christian.koenig@amd.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Dave Airlie <airlied@gmail.com>,
Simona Vetter <simona.vetter@ffwll.ch>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm: Provide a drm_dev_release_barrier() function to wait for device release callbacks
Date: Mon, 16 Mar 2026 18:42:52 +0100 [thread overview]
Message-ID: <9a5f1dab-eeba-477a-84cc-8e565b9c5de6@amd.com> (raw)
In-Reply-To: <20260316162002.13479-2-thomas.hellstrom@linux.intel.com>
On 3/16/26 17:20, Thomas Hellström wrote:
> If helper components, like for example drm_pagemap hold references to
> drm devices, it's typically possible for the drm driver module to be
> unloaded without that reference being dropped,
That is an extremely bad idea to begin with, drm_devices should reference the module who issued them.
> resulting in execution out
> of freed memory. Such components are therefore required to hold a
> module refcount on the module that created the drm device, and ensure
> that module reference is dropped after all references to the drm
> device are dropped.
>
> To relax that, drivers can keep a drm device-count and ensure that the
> module isn't unloaded until the drm device-count has dropped to zero
> and that the caller that decremented the last device-count has finished
> executing driver callbacks.
Stop for a second. The question is why would anybody want to relax that?
That unbinding a driver from a device is separated from module unloading is a design we had in Linux since the very beginning.
Regards,
Christian.
>
> To help with the latter, add a drm_dev_release_barrier() function.
> The function ensures that any caller that has started executing
> device release callbacks has also finished executing them.
>
> Use SRCU for the implementation.
>
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> ---
> drivers/gpu/drm/drm_drv.c | 25 +++++++++++++++++++++++++
> include/drm/drm_drv.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 2915118436ce..9fa72adf173d 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -898,21 +898,46 @@ struct drm_device *drm_dev_alloc(const struct drm_driver *driver,
> }
> EXPORT_SYMBOL(drm_dev_alloc);
>
> +DEFINE_STATIC_SRCU(drm_dev_release_srcu);
> +
> static void drm_dev_release(struct kref *ref)
> {
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
> + int idx;
>
> /* Just in case register/unregister was never called */
> drm_debugfs_dev_fini(dev);
>
> + idx = srcu_read_lock(&drm_dev_release_srcu);
> if (dev->driver->release)
> dev->driver->release(dev);
>
> drm_managed_release(dev);
> + srcu_read_unlock(&drm_dev_release_srcu, idx);
>
> kfree(dev->managed.final_kfree);
> }
>
> +/**
> + * drm_dev_release_barrier() - Ensure drm device release callbacks are finished
> + *
> + * If a device release method or any of the drm managed release callbacks
> + * have been called for a device, wait until all of them have finished
> + * executing. This function can be used to help determine whether it's safe
> + * to unload a driver module.
> + *
> + * Assume for example the driver maintains a device count which is decremented
> + * using a drmm callback or a device release callback. From a drm device
> + * lifetime POV, it's then safe to unload the driver when that device-count
> + * has reached zero and drm_dev_release_barrier() has been called.
> + */
> +void drm_dev_release_barrier(void)
> +{
> + synchronize_srcu(&drm_dev_release_srcu);
> +}
> +EXPORT_SYMBOL(drm_dev_release_barrier);
> +
> +
> /**
> * drm_dev_get - Take reference of a DRM device
> * @dev: device to take reference of or NULL
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 42fc085f986d..b288a885cf45 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -489,6 +489,7 @@ void drm_dev_exit(int idx);
> void drm_dev_unplug(struct drm_device *dev);
> int drm_dev_wedged_event(struct drm_device *dev, unsigned long method,
> struct drm_wedge_task_info *info);
> +void drm_dev_release_barrier(void);
>
> /**
> * drm_dev_is_unplugged - is a DRM device unplugged
next prev parent reply other threads:[~2026-03-16 17:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-16 16:20 [PATCH 0/2] drm,drm/xe: Relax helper module reference requirement Thomas Hellström
2026-03-16 16:20 ` [PATCH 1/2] drm: Provide a drm_dev_release_barrier() function to wait for device release callbacks Thomas Hellström
2026-03-16 17:42 ` Christian König [this message]
2026-03-16 20:10 ` Thomas Hellström
2026-03-16 20:36 ` Thomas Hellström
2026-03-16 16:20 ` [PATCH 2/2] drm/xe: Don't unload the driver until all drm devices are freed Thomas Hellström
2026-03-16 19:52 ` ✗ CI.checkpatch: warning for drm,drm/xe: Relax helper module reference requirement Patchwork
2026-03-16 19:54 ` ✓ CI.KUnit: success " Patchwork
2026-03-16 20:29 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-17 18:28 ` ✗ Xe.CI.FULL: failure " Patchwork
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=9a5f1dab-eeba-477a-84cc-8e565b9c5de6@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
/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