dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Revert "drm/core: Preserve the framebuffer after removing it."
@ 2016-05-19 15:15 Hans de Goede
  2016-05-19 15:33 ` Daniel Vetter
  0 siblings, 1 reply; 3+ messages in thread
From: Hans de Goede @ 2016-05-19 15:15 UTC (permalink / raw)
  To: Dave Airlie
  Cc: Maarten Lankhorst, David Herrmann, Daniel Vetter, dri-devel,
	stable, Hans de Goede, stable

This reverts commit 13803132818c ("drm/core: Preserve the framebuffer
after removing it.").

This commit assumes that going through drm_framebuffer_remove() is not
necessary because "the fbdev code or any system compositor should restore
the planes anyway so there's no need to do it twice". But this is not true
for secondary GPUs / slave outputs.

This revert fixes the dgpu no longer suspending on laptops with
switchable graphics after an external output which is connected
to the dgpu has been used.

And it fixes the WARN_ON to detect drm_framebuffer leaks in
drm_mode_config_cleanup() triggering when unplugging an USB displaylink
device; or when rmmod-ing the secondary GPU kms driver on laptops with
switchable-graphics.

Also this part of the reverted commit's commit-msg: "The old fb_id is
zero'd, so there's no danger of being able to restore the fb from fb_id."
is no longer true, the zero-ing does not happen until drm_framebuffer_free
gets called, which does not happen until the last ref is dropped, so
if a crtc's primary->fb is still pointing to this fb, the id will not
get zero'd and userspace could potentially gain access to the removed
fb again.

Cc: stable@vger.kenrel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/gpu/drm/drm_crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e08f962..15f5cd7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3474,7 +3474,7 @@ int drm_mode_rmfb(struct drm_device *dev,
 	mutex_unlock(&dev->mode_config.fb_lock);
 	mutex_unlock(&file_priv->fbs_lock);
 
-	drm_framebuffer_unreference(fb);
+	drm_framebuffer_remove(fb);
 
 	return 0;
 
@@ -3656,8 +3656,8 @@ void drm_fb_release(struct drm_file *priv)
 	list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
 		list_del_init(&fb->filp_head);
 
-		/* This drops the fpriv->fbs reference. */
-		drm_framebuffer_unreference(fb);
+		/* This will also drop the fpriv->fbs reference. */
+		drm_framebuffer_remove(fb);
 	}
 }
 
-- 
2.7.4

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

* Re: [PATCH] Revert "drm/core: Preserve the framebuffer after removing it."
  2016-05-19 15:15 [PATCH] Revert "drm/core: Preserve the framebuffer after removing it." Hans de Goede
@ 2016-05-19 15:33 ` Daniel Vetter
  2016-05-20  9:58   ` Hans de Goede
  0 siblings, 1 reply; 3+ messages in thread
From: Daniel Vetter @ 2016-05-19 15:33 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Dave Airlie, Maarten Lankhorst, David Herrmann, dri-devel, stable,
	stable

On Thu, May 19, 2016 at 5:15 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> This reverts commit 13803132818c ("drm/core: Preserve the framebuffer
> after removing it.").
>
> This commit assumes that going through drm_framebuffer_remove() is not
> necessary because "the fbdev code or any system compositor should restore
> the planes anyway so there's no need to do it twice". But this is not true
> for secondary GPUs / slave outputs.
>
> This revert fixes the dgpu no longer suspending on laptops with
> switchable graphics after an external output which is connected
> to the dgpu has been used.
>
> And it fixes the WARN_ON to detect drm_framebuffer leaks in
> drm_mode_config_cleanup() triggering when unplugging an USB displaylink
> device; or when rmmod-ing the secondary GPU kms driver on laptops with
> switchable-graphics.
>
> Also this part of the reverted commit's commit-msg: "The old fb_id is
> zero'd, so there's no danger of being able to restore the fb from fb_id."
> is no longer true, the zero-ing does not happen until drm_framebuffer_free
> gets called, which does not happen until the last ref is dropped, so
> if a crtc's primary->fb is still pointing to this fb, the id will not
> get zero'd and userspace could potentially gain access to the removed
> fb again.
>
> Cc: stable@vger.kenrel.org
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

We have a proper fix in drm-next:

commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Wed May 4 14:38:26 2016 +0200

    drm/core: Do not preserve framebuffer on rmfb, v4.

That thing took forever to get merged since no one seemed to have
cared and bothered with a tested-by. But it's on its way to stable
kernels now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

* Re: [PATCH] Revert "drm/core: Preserve the framebuffer after removing it."
  2016-05-19 15:33 ` Daniel Vetter
@ 2016-05-20  9:58   ` Hans de Goede
  0 siblings, 0 replies; 3+ messages in thread
From: Hans de Goede @ 2016-05-20  9:58 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: stable, stable, dri-devel, Dave Airlie

Hi,

On 19-05-16 17:33, Daniel Vetter wrote:
> On Thu, May 19, 2016 at 5:15 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> This reverts commit 13803132818c ("drm/core: Preserve the framebuffer
>> after removing it.").
>>
>> This commit assumes that going through drm_framebuffer_remove() is not
>> necessary because "the fbdev code or any system compositor should restore
>> the planes anyway so there's no need to do it twice". But this is not true
>> for secondary GPUs / slave outputs.
>>
>> This revert fixes the dgpu no longer suspending on laptops with
>> switchable graphics after an external output which is connected
>> to the dgpu has been used.
>>
>> And it fixes the WARN_ON to detect drm_framebuffer leaks in
>> drm_mode_config_cleanup() triggering when unplugging an USB displaylink
>> device; or when rmmod-ing the secondary GPU kms driver on laptops with
>> switchable-graphics.
>>
>> Also this part of the reverted commit's commit-msg: "The old fb_id is
>> zero'd, so there's no danger of being able to restore the fb from fb_id."
>> is no longer true, the zero-ing does not happen until drm_framebuffer_free
>> gets called, which does not happen until the last ref is dropped, so
>> if a crtc's primary->fb is still pointing to this fb, the id will not
>> get zero'd and userspace could potentially gain access to the removed
>> fb again.
>>
>> Cc: stable@vger.kenrel.org
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> We have a proper fix in drm-next:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Date:   Wed May 4 14:38:26 2016 +0200
>
>     drm/core: Do not preserve framebuffer on rmfb, v4.
>
> That thing took forever to get merged since no one seemed to have
> cared and bothered with a tested-by. But it's on its way to stable
> kernels now.

Ah, excellent, the important thing is that this gets fixed :)

Regards,

Hans
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

end of thread, other threads:[~2016-05-20  9:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-19 15:15 [PATCH] Revert "drm/core: Preserve the framebuffer after removing it." Hans de Goede
2016-05-19 15:33 ` Daniel Vetter
2016-05-20  9:58   ` Hans de Goede

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).