public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <dev@lankhorst.se>
To: dri-devel@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org,
	"Maarten Lankhorst" <dev@lankhorst.se>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Guenter Roeck" <linux@roeck-us.net>,
	"Simona Vetter" <simona.vetter@ffwll.ch>
Subject: [PATCH] Revert "drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug"
Date: Thu, 26 Mar 2026 09:22:18 +0100	[thread overview]
Message-ID: <20260326082217.39941-2-dev@lankhorst.se> (raw)
In-Reply-To: <acRPgts0pCLw8yLq@phenom.ffwll.local>

This reverts commit 6bee098b91417654703e17eb5c1822c6dfd0c01d.

Den 2026-03-25 kl. 22:11, skrev Simona Vetter:
> On Wed, Mar 25, 2026 at 10:26:40AM -0700, Guenter Roeck wrote:
>> Hi,
>>
>> On Fri, Mar 13, 2026 at 04:17:27PM +0100, Maarten Lankhorst wrote:
>>> When trying to do a rather aggressive test of igt's "xe_module_load
>>> --r reload" with a full desktop environment and game running I noticed
>>> a few OOPSes when dereferencing freed pointers, related to
>>> framebuffers and property blobs after the compositor exits.
>>>
>>> Solve this by guarding the freeing in drm_file with drm_dev_enter/exit,
>>> and immediately put the references from struct drm_file objects during
>>> drm_dev_unplug().
>>>
>>
>> With this patch in v6.18.20, I get the warning backtraces below.
>> The backtraces are gone with the patch reverted.
>
> Yeah, this needs to be reverted, reasoning below. Maarten, can you please
> take care of that and feed the revert through the usual channels? I don't
> think it's critical enough that we need to fast-track this into drm.git
> directly.
>
> Quoting the patch here again:
>
>>  drivers/gpu/drm/drm_file.c        | 5 ++++-
>>  drivers/gpu/drm/drm_mode_config.c | 9 ++++++---
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
>> index ec820686b3021..f52141f842a1f 100644
>> --- a/drivers/gpu/drm/drm_file.c
>> +++ b/drivers/gpu/drm/drm_file.c
>> @@ -233,6 +233,7 @@ static void drm_events_release(struct drm_file *file_priv)
>>  void drm_file_free(struct drm_file *file)
>>  {
>>  	struct drm_device *dev;
>> +	int idx;
>>
>>  	if (!file)
>>  		return;
>> @@ -249,9 +250,11 @@ void drm_file_free(struct drm_file *file)
>>
>>  	drm_events_release(file);
>>
>> -	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> +	if (drm_core_check_feature(dev, DRIVER_MODESET) &&
>> +	    drm_dev_enter(dev, &idx)) {
>
> This is misplaced for two reasons:
>
> - Even if we'd want to guarantee that we hold a drm_dev_enter/exit
>   reference during framebuffer teardown, we'd need to do this
>   _consistently over all callsites. Not ad-hoc in just one place that a
>   testcase hits. This also means kerneldoc updates of the relevant hooks
>   and at least a bunch of acks from other driver people to document the
>   consensus.
>
> - More importantly, this is driver responsibilities in general unless we
>   have extremely good reasons to the contrary. Which means this must be
>   placed in xe.
>
>>  		drm_fb_release(file);
>>  		drm_property_destroy_user_blobs(dev, file);
>> +		drm_dev_exit(idx);
>>  	}
>>
>>  	if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
>> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
>> index 84ae8a23a3678..e349418978f79 100644
>> --- a/drivers/gpu/drm/drm_mode_config.c
>> +++ b/drivers/gpu/drm/drm_mode_config.c
>> @@ -583,10 +583,13 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>>  	 */
>>  	WARN_ON(!list_empty(&dev->mode_config.fb_list));
>>  	list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) {
>> -		struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]");
>> +		if (list_empty(&fb->filp_head) || drm_framebuffer_read_refcount(fb) > 1) {
>> +			struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]");
>
> This is also wrong:
>
> - Firstly, it's a completely independent bug, we do not smash two bugfixes
>   into one patch.
>
> - Secondly, it's again a driver bug: drm_mode_cleanup must be called when
>   the last drm_device reference disappears (hence the existence of
>   drmm_mode_config_init), not when the driver gets unbound. The fact that
>   this shows up in a callchain from a devres cleanup means the intel
>   driver gets this wrong (like almost everyone else because historically
>   we didn't know better).
>
>   If we don't follow this rule, then we get races with this code here
>   running concurrently with drm_file fb cleanups, which just does not
>   work. Review pointed that out, but then shrugged it off with a confused
>   explanation:
>
>   https://lore.kernel.org/all/e61e64c796ccfb17ae673331a3df4b877bf42d82.camel@linux.intel.com/
>
>   Yes this also means a lot of the other drm_device teardown that drivers
>   do happens way too early. There is a massive can of worms here of a
>   magnitude that most likely is much, much bigger than what you can
>   backport to stable kernels. Hotunplug is _hard_.

Back to the drawing board, and fixing it in the intel display driver
instead.

Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Fixes: 6bee098b9141 ("drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug")
---
 drivers/gpu/drm/drm_file.c        | 5 +----
 drivers/gpu/drm/drm_mode_config.c | 9 +++------
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index f52141f842a1f..ec820686b3021 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -233,7 +233,6 @@ static void drm_events_release(struct drm_file *file_priv)
 void drm_file_free(struct drm_file *file)
 {
 	struct drm_device *dev;
-	int idx;
 
 	if (!file)
 		return;
@@ -250,11 +249,9 @@ void drm_file_free(struct drm_file *file)
 
 	drm_events_release(file);
 
-	if (drm_core_check_feature(dev, DRIVER_MODESET) &&
-	    drm_dev_enter(dev, &idx)) {
+	if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 		drm_fb_release(file);
 		drm_property_destroy_user_blobs(dev, file);
-		drm_dev_exit(idx);
 	}
 
 	if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 802bc4608abf5..d12db9b0bab81 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -577,13 +577,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 	 */
 	WARN_ON(!list_empty(&dev->mode_config.fb_list));
 	list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list, head) {
-		if (list_empty(&fb->filp_head) || drm_framebuffer_read_refcount(fb) > 1) {
-			struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]");
+		struct drm_printer p = drm_dbg_printer(dev, DRM_UT_KMS, "[leaked fb]");
 
-			drm_printf(&p, "framebuffer[%u]:\n", fb->base.id);
-			drm_framebuffer_print_info(&p, 1, fb);
-		}
-		list_del_init(&fb->filp_head);
+		drm_printf(&p, "framebuffer[%u]:\n", fb->base.id);
+		drm_framebuffer_print_info(&p, 1, fb);
 		drm_framebuffer_free(&fb->base.refcount);
 	}
 
-- 
2.51.0


  reply	other threads:[~2026-03-26  8:22 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-13 15:17 [PATCH v2 0/1] Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug Maarten Lankhorst
2026-03-13 15:17 ` [PATCH v2 1/1] drm: " Maarten Lankhorst
2026-03-17 15:26   ` Thomas Hellström
2026-03-17 15:39     ` Maarten Lankhorst
2026-03-17 15:43       ` Hellstrom, Thomas
2026-03-17 16:59         ` Maarten Lankhorst
2026-03-25 17:26   ` Guenter Roeck
2026-03-25 18:05     ` Maarten Lankhorst
2026-03-25 18:26       ` Guenter Roeck
2026-03-25 18:17     ` Maarten Lankhorst
2026-03-25 18:28     ` Maarten Lankhorst
2026-03-25 18:59       ` Guenter Roeck
2026-03-25 20:12       ` Guenter Roeck
2026-03-25 20:31         ` Maarten Lankhorst
2026-03-25 21:07           ` Guenter Roeck
2026-03-25 21:11     ` Simona Vetter
2026-03-26  8:22       ` Maarten Lankhorst [this message]
2026-03-26 11:24         ` [PATCH] Revert "drm: Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug" Guenter Roeck
2026-03-13 15:29 ` ✗ CI.checkpatch: warning for Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug (rev2) Patchwork
2026-03-13 15:30 ` ✓ CI.KUnit: success " Patchwork
2026-03-13 16:09 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-14 19:51 ` ✓ Xe.CI.FULL: " Patchwork
2026-03-25 18:33 ` ✗ CI.checkpatch: warning for Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug (rev3) Patchwork
2026-03-25 18:34 ` ✓ CI.KUnit: success " Patchwork
2026-03-25 19:29 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-25 20:35 ` ✗ CI.checkpatch: warning for Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug (rev4) Patchwork
2026-03-25 20:37 ` ✓ CI.KUnit: success " Patchwork
2026-03-25 21:10 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-26  6:48 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-03-26  8:27 ` ✗ CI.checkpatch: warning for Fix use-after-free on framebuffers and property blobs when calling drm_dev_unplug (rev5) Patchwork
2026-03-26  8:28 ` ✓ CI.KUnit: success " Patchwork
2026-03-26  9:03 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-26 20:53 ` ✓ Xe.CI.FULL: " 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=20260326082217.39941-2-dev@lankhorst.se \
    --to=dev@lankhorst.se \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux@roeck-us.net \
    --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