Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752538AbdDKDFA (ORCPT ); Mon, 10 Apr 2017 23:05:00 -0400 Received: from regular1.263xmail.com ([211.150.99.130]:50197 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751564AbdDKDE7 (ORCPT ); Mon, 10 Apr 2017 23:04:59 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: jeffy.chen@rock-chips.com X-FST-TO: seanpaul@chromium.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <58EC47C7.50801@rock-chips.com> Date: Tue, 11 Apr 2017 11:04:39 +0800 From: jeffy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20130126 Thunderbird/19.0 MIME-Version: 1.0 To: Sean Paul CC: linux-kernel@vger.kernel.org, briannorris@chromium.org, dianders@chromium.org, tfiga@chromium.org, zyw@rock-chips.com, marcheu@chromium.org, mark.yao@rock-chips.com, hshi@chromium.org, Daniel Vetter , Jani Nikula , dri-devel@lists.freedesktop.org, David Airlie Subject: Re: [PATCH v6 2/2] drm: Prevent release fb after cleanup mode config References: <1491818445-11409-1-git-send-email-jeffy.chen@rock-chips.com> <1491818445-11409-3-git-send-email-jeffy.chen@rock-chips.com> <20170410203126.bfufxn3yijqq7f7y@art_vandelay> In-Reply-To: <20170410203126.bfufxn3yijqq7f7y@art_vandelay> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1695 Lines: 59 Hi Sean, On 04/11/2017 04:31 AM, Sean Paul wrote: > On Mon, Apr 10, 2017 at 06:00:45PM +0800, Jeffy Chen wrote: >> After unbinding drm, the user space may still owns the drm dev fd, >> and may trigger fb release after cleanup mode config. >> >> Add a sanity check to prevent that. >> >> Signed-off-by: Jeffy Chen >> --- >> >> Changes in v6: None >> Changes in v5: None >> Changes in v2: None >> >> drivers/gpu/drm/drm_framebuffer.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c >> index e8f9c13..03c1632 100644 >> --- a/drivers/gpu/drm/drm_framebuffer.c >> +++ b/drivers/gpu/drm/drm_framebuffer.c >> @@ -583,6 +583,11 @@ void drm_fb_release(struct drm_file *priv) >> { >> struct drm_framebuffer *fb, *tfb; >> struct drm_mode_rmfb_work arg; >> + struct drm_minor *minor = priv->minor; >> + struct drm_device *dev = minor->dev; >> + >> + if (WARN_ON(!dev->mode_config.num_fb && !list_empty(&priv->fbs))) > > Have you actually seen this happen? num_fb should be tightly couple to > priv->fbs, so it seems like this could only result from a driver bug (or I'm not > reading the code correctly). yes, 100% repro by: 1/ start display server 2/ unbind drm 3/ stop display server the num_fb would be decreased(with a warning in drm_mode_config_cleanup's fb_list check) in drm_mode_config_cleanup->drm_framebuffer_free->rockchip_drm_fb_destroy->drm_framebuffer_cleanup this flow would not modify the priv->fbs at the same time. so it would still remains the pointer of those freed fb. > > Sean > >> + return; >> >> INIT_LIST_HEAD(&arg.fbs); >> >> -- >> 2.1.4 >> >