drm/i915: Clear i915->display when no longer valid

Don't leave a stale i915->display pointer hanging around after
the display driver has been torn down. Apparently the gt code
calls into the reset codepaths after this, and if the display
pointer is still around we may try to access freed memory.

The whole teardown sequence here seems rather suspect. Why is
display done first and then everything else via the managed
release? Who the heck knows. Someone really needs to dig into
this stuff and figure out the proper init/cleanup sequence for
both i915 (real and mock) and xe...

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260415210411.24750-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
This commit is contained in:
Ville Syrjälä 2026-04-16 00:04:05 +03:00
parent 6c6be62b92
commit 758eedf64b
2 changed files with 2 additions and 0 deletions

View File

@ -310,6 +310,7 @@ static void i915_driver_late_release(struct drm_i915_private *dev_priv)
i915_params_free(&dev_priv->params);
intel_display_device_remove(display);
dev_priv->display = NULL;
}
/**

View File

@ -277,6 +277,7 @@ void mock_destroy_device(struct drm_i915_private *i915)
struct device *dev = i915->drm.dev;
intel_display_device_remove(i915->display);
i915->display = NULL;
devres_release_group(dev, NULL);
put_device(dev);