Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753521AbdDJUba (ORCPT ); Mon, 10 Apr 2017 16:31:30 -0400 Received: from mail-qt0-f169.google.com ([209.85.216.169]:36646 "EHLO mail-qt0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752746AbdDJUb3 (ORCPT ); Mon, 10 Apr 2017 16:31:29 -0400 Date: Mon, 10 Apr 2017 16:31:26 -0400 From: Sean Paul To: Jeffy Chen Cc: linux-kernel@vger.kernel.org, briannorris@chromium.org, dianders@chromium.org, tfiga@chromium.org, seanpaul@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 Message-ID: <20170410203126.bfufxn3yijqq7f7y@art_vandelay> References: <1491818445-11409-1-git-send-email-jeffy.chen@rock-chips.com> <1491818445-11409-3-git-send-email-jeffy.chen@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1491818445-11409-3-git-send-email-jeffy.chen@rock-chips.com> User-Agent: NeoMutt/20170306-66-6ddb52-dirty (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 45 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). Sean > + return; > > INIT_LIST_HEAD(&arg.fbs); > > -- > 2.1.4 > -- Sean Paul, Software Engineer, Google / Chromium OS