From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753502AbdDLIj4 (ORCPT ); Wed, 12 Apr 2017 04:39:56 -0400 Received: from regular1.263xmail.com ([211.150.99.131]:54197 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752515AbdDLIjx (ORCPT ); Wed, 12 Apr 2017 04:39:53 -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: linux-kernel@vger.kernel.org X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: <2362c1b0c107a762978f11adf54cb9d2> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <58EDE7CD.1060506@rock-chips.com> Date: Wed, 12 Apr 2017 16:39:41 +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: linux-kernel@vger.kernel.org, briannorris@chromium.org, dianders@chromium.org, tfiga@chromium.org, dri-devel@lists.freedesktop.org, Daniel Vetter , zyw@rock-chips.com, marcheu@chromium.org, hshi@chromium.org Subject: Re: [PATCH v7 2/2] drm: Prevent release fb after cleanup drm_mode_config References: <1491881502-24357-1-git-send-email-jeffy.chen@rock-chips.com> <1491881502-24357-3-git-send-email-jeffy.chen@rock-chips.com> <20170412063610.55zrqja6uqlfz6lh@phenom.ffwll.local> In-Reply-To: <20170412063610.55zrqja6uqlfz6lh@phenom.ffwll.local> 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 Hi Daniel, On 04/12/2017 02:36 PM, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 11:31:42AM +0800, Jeffy Chen wrote: >> We are freeing all framebuffers in drm_mode_config_cleanup without >> sync the drm_file's fbs list. >> >> So if someone try to unbind drm before release drm dev fd, the fbs >> list would remain some invalid fb references. And that would cause >> crash later in drm_fb_release. >> >> Add a sanity check to prevent that. >> >> Signed-off-by: Jeffy Chen > > This feels like duct-tape. The problem is that when we unplug a drm > device, we don't properly clean this up. I think we should first clean up > all the drm files (and make sure all ioctl and anything else completed), > before we proceed further in the driver cleanup. > > Like I said, fixing unplug is going to be serious amounts of work, not > sure you really want to do this just for a pure debug use-cases. > -Daniel right, and it's ok to drop this 2 patches, the rests are already enough for the testing :) > >> >> --- >> >> Changes in v7: >> Update commit message. >> >> 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))) >> + return; >> >> INIT_LIST_HEAD(&arg.fbs); >> >> -- >> 2.1.4 >> >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >