All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krzysztof Niemiec" <krzysztof.niemiec@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm: Unwind drm device registration upon error
Date: Thu, 27 Aug 2026 14:52:27 +0000	[thread overview]
Message-ID: <20260827145228.478961F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260827143447.99553-2-krzysztof.niemiec@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Debugfs pollution due to early destruction of dev->debugfs_root in drm_dev_register() error path.
--

commit d5c910dd66292cf0f42ddf2dd15a2566f8663a8a
Author: Krzysztof Karas <krzysztof.karas@intel.com>

drm: Unwind drm device registration upon error

The drm device registration is done via drm_dev_register().
This function attempts to undo some of the initiatlization steps
under err_unload and err_minors labels, but this process is
incomplete - debugfs entries remain and the dev->registered flag
is still set to true.

> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index cb53baa70995f..2d964c9535f49 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -1144,6 +1144,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long flags)
>  	drm_minor_unregister(dev, DRM_MINOR_ACCEL);
>  	drm_minor_unregister(dev, DRM_MINOR_PRIMARY);
>  	drm_minor_unregister(dev, DRM_MINOR_RENDER);
> +	drm_debugfs_dev_fini(dev);

[Severity: Medium]
Will this cause debugfs pollution if a driver retries registration after a
failure?

In drivers like amdgpu, there is a retry mechanism for registration:

drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:amdgpu_pci_probe() {
    ...
retry_init:
	ret = drm_dev_register(ddev, flags);
	if (ret == -EAGAIN && ++retry <= 3) {
		drm_info(adev_to_drm(adev), "retry init %d\n", retry);
		/* Don't request EX mode too frequently which is attacking */
		msleep(5000);
		goto retry_init;
	}
    ...
}

Because dev->debugfs_root is initialized during drm_dev_init(), calling
drm_debugfs_dev_fini() here in the error path of drm_dev_register() destroys
the directory and permanently sets dev->debugfs_root to NULL.

If the driver retries drm_dev_register() on the same device instance,
drm_debugfs_dev_register() will pass the NULL dev->debugfs_root to
debugfs_create_file(). This causes device-specific debugfs files (like
'clients', 'gem_names', 'framebuffer') to be created in the global debugfs
root (/sys/kernel/debug/) instead of the device-specific directory, polluting
the global namespace and causing naming collisions.

Should dev->debugfs_root only be destroyed in drm_dev_release() to maintain
object lifecycle symmetry?

> +	dev->registered = false;
>  out_unlock:
>  	if (drm_dev_needs_global_mutex(dev))
>  		mutex_unlock(&drm_global_mutex);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827143447.99553-1-krzysztof.niemiec@intel.com?part=1

  reply	other threads:[~2026-08-27 14:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27 14:34 [PATCH v3 0/2] DRM device registration fixes Krzysztof Niemiec
2026-08-27 14:34 ` [PATCH v3 1/2] drm: Unwind drm device registration upon error Krzysztof Niemiec
2026-08-27 14:52   ` sashiko-bot [this message]
2026-08-27 23:14   ` Andi Shyti
2026-09-02 10:41     ` Krzysztof Niemiec
2026-09-10  8:23       ` Andi Shyti
2026-08-27 14:34 ` [PATCH v3 2/2] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
2026-08-27 16:51 ` ✓ i915.CI.BAT: success for DRM device registration fixes (rev2) Patchwork
2026-08-27 20:39 ` ✗ i915.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=20260827145228.478961F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=krzysztof.niemiec@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.