From: sashiko-bot@kernel.org
To: "Sebastian Wick" <sebastian.wick@redhat.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/vkms: Use drm_dev_unplug() for ConfigFS device removal
Date: Sat, 31 Oct 2026 23:18:42 +0000 [thread overview]
Message-ID: <sashiko-outbox-192219@kernel.org> (raw)
In-Reply-To: <20261031225901.3200167-2-sebastian.wick@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/vkms: broken CRC debugfs unplug handling in vkms_destroy()
--
commit 58c6203197ea5aa86a82e01783503c18d44dd2a1
Author: Sebastian Wick <sebastian.wick@redhat.com>
drm/vkms: Use drm_dev_unplug() for ConfigFS device removal
This commit switches vkms_destroy() from drm_dev_unregister() to
drm_dev_unplug() so that ioctls on open file descriptors are rejected with
-ENODEV and in-flight operations guarded by drm_dev_enter()/drm_dev_exit()
complete before ConfigFS device removal proceeds.
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 5a640b531d88f..716f9c966c211 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -259,7 +259,7 @@ void vkms_destroy(struct vkms_config *config)
>
> fdev = config->dev->faux_dev;
>
> - drm_dev_unregister(&config->dev->drm);
> + drm_dev_unplug(&config->dev->drm);
> drm_atomic_helper_shutdown(&config->dev->drm);
> devres_release_group(&fdev->dev, NULL);
[Severity: High]
How does this interact with an open CRTC CRC debugfs file descriptor
(/sys/kernel/debug/dri/<N>/crtc-<M>/crc/data) when the VKMS device is
disabled via ConfigFS?
In drivers/gpu/drm/vkms/vkms_composer.c, vkms_set_crc_source() guards the
callback with drm_dev_enter():
drivers/gpu/drm/vkms/vkms_composer.c:vkms_set_crc_source() {
...
if (!drm_dev_enter(crtc->dev, &idx))
return -ENODEV;
ret = vkms_crc_parse_source(src_name, &enabled);
vkms_set_composer(out, enabled);
drm_dev_exit(idx);
return ret;
}
When the crc/data file descriptor is closed, full_proxy_release() invokes
crtc_crc_release() in drivers/gpu/drm/drm_debugfs_crc.c, which calls
crtc->funcs->set_crc_source(crtc, NULL).
Two issues seem possible here:
1. Unlike /dev/dri/card<N> file descriptors, opening crc/data via
crtc_crc_open() does not acquire a drm_dev_get() reference on crtc->dev,
and debugfs_remove_recursive() during drm_dev_unregister() does not wait
for open file descriptors to close.
In vkms_destroy(), drm_dev_unplug() runs synchronize_srcu() before
devres_release_group(&fdev->dev, NULL) drops the devm reference via
devm_drm_dev_init_release() -> drm_dev_put(). If no /dev/dri/card<N> fd is
open (or after it is closed first, such as during process exit when card<N>
has a lower fd number than crc/data), drm_dev_release() frees struct
vkms_output (embedding struct drm_crtc) and struct vkms_device (embedding
struct drm_device). When the crc/data fd is subsequently closed, wouldn't
crtc_crc_release() and drm_dev_enter(crtc->dev, &idx) in
vkms_set_crc_source() dereference the freed struct drm_crtc and
crtc->dev?
2. Conversely, if struct drm_device is still kept alive by an open
/dev/dri/card<N> fd when crc/data is closed after drm_dev_unplug() sets
dev->unplugged = true, drm_dev_enter(crtc->dev, &idx) in
vkms_set_crc_source(crtc, NULL) will return false and exit early with
-ENODEV. Doesn't that skip vkms_set_composer(out, false), leaving
out->composer_enabled set to true and leaking the vblank reference from
drm_crtc_vblank_put(&out->crtc)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261031225901.3200167-1-sebastian.wick@redhat.com?part=2
prev parent reply other threads:[~2026-10-31 23:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-31 22:58 [PATCH 1/2] drm/vkms: Add drm_dev_enter/exit guards for hot-removable paths Sebastian Wick
2026-10-31 22:58 ` [PATCH 2/2] drm/vkms: Use drm_dev_unplug() for ConfigFS device removal Sebastian Wick
2026-10-31 23:18 ` sashiko-bot [this message]
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=sashiko-outbox-192219@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sebastian.wick@redhat.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 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.