From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:49743 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755186AbcETJ6t (ORCPT ); Fri, 20 May 2016 05:58:49 -0400 Subject: Re: [PATCH] Revert "drm/core: Preserve the framebuffer after removing it." To: Daniel Vetter References: <1463670901-31153-1-git-send-email-hdegoede@redhat.com> Cc: Dave Airlie , Maarten Lankhorst , David Herrmann , dri-devel , stable , stable@vger.kenrel.org From: Hans de Goede Message-ID: <014fdfb5-b8a6-5c79-cabb-ab27a32d9f7b@redhat.com> Date: Fri, 20 May 2016 11:58:43 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: Hi, On 19-05-16 17:33, Daniel Vetter wrote: > On Thu, May 19, 2016 at 5:15 PM, Hans de Goede 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 > > We have a proper fix in drm-next: > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst > 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