public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
@ 2026-05-22 15:43 Krzysztof Niemiec
  2026-05-25  7:38 ` Sebastian Brzezinka
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Krzysztof Niemiec @ 2026-05-22 15:43 UTC (permalink / raw)
  To: intel-gfx
  Cc: dri-devel, Andi Shyti, Janusz Krzysztofik, Krzysztof Karas,
	Sebastian Brzezinka, Krzysztof Niemiec

During driver probe, in i915_driver_register(), if drm_dev_register()
fails, the code enters into an error path. In it, a call to
drm_dev_unregister() is made as part of cleanup in case drm_dev_register()
returns an error. However, this is unnecessary, as in case of an error
drm_dev_register() undoes its own setup in its own error path.

Calling drm_dev_unregister() after a failed drm_dev_register() also
generates a superfluous WARN_ON() from drm_client_sysrq_unregister().
drm_client_sysrq_register() is only called in drm_dev_register() if
there was no error in the latter. drm_dev_unregister() calls
drm_client_sysrq_unregister() as it expects to be called after a successful
drm_dev_register(), in which case the _sysrq_register() counterpart is
called. However, if the call to drm_dev_register() failed,
_sysrq_register() is never called; calling drm_dev_unregister() will
cause _sysrq_unregister() to be called (unconditionally) with no
corresponding _sysrq_register() call before it, which is caught in the
aforementioned WARN_ON().

Remove the redundant call to drm_dev_unregister() in case
drm_dev_register() returns an error.

Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
---
 drivers/gpu/drm/i915/i915_driver.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
index c10cab38935a..10e16002050a 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -638,7 +638,6 @@ static int i915_driver_register(struct drm_i915_private *dev_priv)
 	if (ret) {
 		i915_probe_error(dev_priv,
 				 "Failed to register driver for userspace access!\n");
-		drm_dev_unregister(&dev_priv->drm);
 		i915_pmu_unregister(dev_priv);
 		i915_gem_driver_unregister(dev_priv);
 		return ret;
-- 
2.45.2


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
  2026-05-22 15:43 [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
@ 2026-05-25  7:38 ` Sebastian Brzezinka
  2026-05-25  8:11 ` Janusz Krzysztofik
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Sebastian Brzezinka @ 2026-05-25  7:38 UTC (permalink / raw)
  To: Krzysztof Niemiec, intel-gfx
  Cc: dri-devel, Andi Shyti, Janusz Krzysztofik, Krzysztof Karas,
	Sebastian Brzezinka

Hi Krzysztof,

On Fri May 22, 2026 at 5:43 PM CEST, Krzysztof Niemiec wrote:
> During driver probe, in i915_driver_register(), if drm_dev_register()
> fails, the code enters into an error path. In it, a call to
> drm_dev_unregister() is made as part of cleanup in case drm_dev_register()
> returns an error. However, this is unnecessary, as in case of an error
> drm_dev_register() undoes its own setup in its own error path.
>
> Calling drm_dev_unregister() after a failed drm_dev_register() also
> generates a superfluous WARN_ON() from drm_client_sysrq_unregister().
> drm_client_sysrq_register() is only called in drm_dev_register() if
> there was no error in the latter. drm_dev_unregister() calls
> drm_client_sysrq_unregister() as it expects to be called after a successful
> drm_dev_register(), in which case the _sysrq_register() counterpart is
> called. However, if the call to drm_dev_register() failed,
> _sysrq_register() is never called; calling drm_dev_unregister() will
> cause _sysrq_unregister() to be called (unconditionally) with no
> corresponding _sysrq_register() call before it, which is caught in the
> aforementioned WARN_ON().
>
> Remove the redundant call to drm_dev_unregister() in case
> drm_dev_register() returns an error.
>
> Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_driver.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> index c10cab38935a..10e16002050a 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -638,7 +638,6 @@ static int i915_driver_register(struct drm_i915_private *dev_priv)
>  	if (ret) {
>  		i915_probe_error(dev_priv,
>  				 "Failed to register driver for userspace access!\n");
> -		drm_dev_unregister(&dev_priv->drm);
Overall, the patch looks reasonable to me, but I need to doublecheck
it. It is definitely missing a Fixes tag. I believe it should be: Fixes:
223038731489

>  		i915_pmu_unregister(dev_priv);
>  		i915_gem_driver_unregister(dev_priv);
>  		return ret;




-- 
Best regards,
Sebastian


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
  2026-05-22 15:43 [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
  2026-05-25  7:38 ` Sebastian Brzezinka
@ 2026-05-25  8:11 ` Janusz Krzysztofik
  2026-05-25  8:26 ` Claude review: " Claude Code Review Bot
  2026-05-25  8:26 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Janusz Krzysztofik @ 2026-05-25  8:11 UTC (permalink / raw)
  To: Krzysztof Niemiec, intel-gfx
  Cc: dri-devel, Andi Shyti, Krzysztof Karas, Sebastian Brzezinka

Hi Krzysztof,

On Fri, 2026-05-22 at 17:43 +0200, Krzysztof Niemiec wrote:
> During driver probe, in i915_driver_register(), if drm_dev_register()
> fails, the code enters into an error path. In it, a call to
> drm_dev_unregister() is made as part of cleanup in case drm_dev_register()
> returns an error. However, this is unnecessary, as in case of an error
> drm_dev_register() undoes its own setup in its own error path.

Doesn't this patch depend on your "drm: Set dev->registered back to false
in case of register failure"?  While each of the two touches a separate
area of responsibility, I would submit them as a series if that dependency
exists.

Thanks,
Janusz

> 
> Calling drm_dev_unregister() after a failed drm_dev_register() also
> generates a superfluous WARN_ON() from drm_client_sysrq_unregister().
> drm_client_sysrq_register() is only called in drm_dev_register() if
> there was no error in the latter. drm_dev_unregister() calls
> drm_client_sysrq_unregister() as it expects to be called after a successful
> drm_dev_register(), in which case the _sysrq_register() counterpart is
> called. However, if the call to drm_dev_register() failed,
> _sysrq_register() is never called; calling drm_dev_unregister() will
> cause _sysrq_unregister() to be called (unconditionally) with no
> corresponding _sysrq_register() call before it, which is caught in the
> aforementioned WARN_ON().
> 
> Remove the redundant call to drm_dev_unregister() in case
> drm_dev_register() returns an error.
> 
> Signed-off-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_driver.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c
> index c10cab38935a..10e16002050a 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -638,7 +638,6 @@ static int i915_driver_register(struct drm_i915_private *dev_priv)
>  	if (ret) {
>  		i915_probe_error(dev_priv,
>  				 "Failed to register driver for userspace access!\n");
> -		drm_dev_unregister(&dev_priv->drm);
>  		i915_pmu_unregister(dev_priv);
>  		i915_gem_driver_unregister(dev_priv);
>  		return ret;

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Claude review: drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
  2026-05-22 15:43 [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
                   ` (2 preceding siblings ...)
  2026-05-25  8:26 ` Claude review: " Claude Code Review Bot
@ 2026-05-25  8:26 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-05-25  8:26 UTC (permalink / raw)
  To: dri-devel-reviews

Overall Series Review

Subject: drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
Author: Krzysztof Niemiec <krzysztof.niemiec@intel.com>
Patches: 3
Reviewed: 2026-05-25T18:26:20.389509

---

This is a single-patch series that removes a redundant `drm_dev_unregister()` call from the error path of `i915_driver_register()` when `drm_dev_register()` fails. The analysis in the commit message is correct and the fix is appropriate. The patch is clean, minimal, and well-justified.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Claude review: drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register()
  2026-05-22 15:43 [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
  2026-05-25  7:38 ` Sebastian Brzezinka
  2026-05-25  8:11 ` Janusz Krzysztofik
@ 2026-05-25  8:26 ` Claude Code Review Bot
  2026-05-25  8:26 ` Claude Code Review Bot
  3 siblings, 0 replies; 5+ messages in thread
From: Claude Code Review Bot @ 2026-05-25  8:26 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Verdict: Looks good.**

The commit message accurately describes the problem and the fix. I verified each claim:

1. **`drm_dev_register()` cleans up after itself on failure.** Confirmed in `drm_drv.c:1115-1123` — on error, `drm_dev_register()` jumps to `err_minors` which calls `remove_compat_control_link()`, `drm_minor_unregister()` for all three minor types, then returns the error. So calling `drm_dev_unregister()` after a failed `drm_dev_register()` is indeed double-cleanup.

2. **`drm_client_sysrq_register()` is only called on success.** Confirmed at `drm_drv.c:1105` — `drm_client_sysrq_register(dev)` is called just before the success return, after both `err_unload` and `err_minors` labels. If `drm_dev_register()` fails, this call never executes.

3. **`drm_client_sysrq_unregister()` triggers a WARN_ON.** Confirmed at `drm_client_sysrq.c:58` — `drm_client_sysrq_unregister()` does `drm_WARN_ON(dev, list_empty(&dev->client_sysrq_list))`. Since `drm_client_sysrq_register()` was never called, the list head is in its initialized (empty) state, triggering the warning.

4. **The remaining error path is correct.** After removing the `drm_dev_unregister()` call, the error path at `i915_driver.c:639-645` still correctly unwinds `i915_pmu_register()` and `i915_gem_driver_register()` which were called earlier in the function at lines 632-633. The `intel_vgpu_register()` at line 635 does not appear to have an unregister counterpart needed in this path (it's a no-op on non-VF), so the cleanup sequence is correct.

5. **Additionally, `drm_dev_unregister()` does more than just undo `drm_dev_register()`** — it also calls `drm_client_dev_unregister()`, `drm_modeset_unregister_all()`, and `drm_debugfs_dev_fini()` (`drm_drv.c:1146-1166`). Calling these when their corresponding register functions were never called (because `drm_dev_register()` failed) is wrong and could cause further issues beyond the WARN_ON.

No concerns with this patch. 

Reviewed-by is warranted.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-05-25  8:26 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-22 15:43 [PATCH] drm/i915: Remove drm_dev_unregister() from the error path during i915_driver_register() Krzysztof Niemiec
2026-05-25  7:38 ` Sebastian Brzezinka
2026-05-25  8:11 ` Janusz Krzysztofik
2026-05-25  8:26 ` Claude review: " Claude Code Review Bot
2026-05-25  8:26 ` Claude Code Review Bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox