Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756781AbdDFM06 (ORCPT ); Thu, 6 Apr 2017 08:26:58 -0400 Received: from mail-qk0-f180.google.com ([209.85.220.180]:35444 "EHLO mail-qk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756055AbdDFM0m (ORCPT ); Thu, 6 Apr 2017 08:26:42 -0400 Date: Thu, 6 Apr 2017 08:26:33 -0400 From: Sean Paul To: jeffy Cc: Sean Paul , linux-kernel@vger.kernel.org, briannorris@chromium.org, dianders@chromium.org, tfiga@chromium.org, zyw@rock-chips.com, mark.yao@rock-chips.com, Heiko Stuebner , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, David Airlie , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid Message-ID: <20170406122633.2t5hf25ozqoohnl2@art_vandelay> References: <1491380967-28570-1-git-send-email-jeffy.chen@rock-chips.com> <1491380967-28570-9-git-send-email-jeffy.chen@rock-chips.com> <20170405162839.k6q4b3tpt6t2s3zm@art_vandelay> <58E5AC5F.5090303@rock-chips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58E5AC5F.5090303@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: 3052 Lines: 88 On Thu, Apr 06, 2017 at 10:47:59AM +0800, jeffy wrote: > Hi Sean, > > On 04/06/2017 12:28 AM, Sean Paul wrote: > > On Wed, Apr 05, 2017 at 04:29:26PM +0800, Jeffy Chen wrote: > > > After unbinding drm, the userspace may still has a chance to access > > > gem buf. > > > > > > Add a sanity check for a NULL dev_private to prevent that from > > > happening. > > > > I still don't understand how this is happening. You're saying that these hooks > > can be called after rockchip_drm_unbind() has finished? > > > yes, tested on chromebook rk3399 kevin with kernel 4.4, if trigger unbind > without killing display service(ui or frecon): > > [ 31.276889] [] dump_backtrace+0x0/0x164 > [ 31.282288] [] show_stack+0x24/0x30 > [ 31.287338] [] dump_stack+0x98/0xb8 > [ 31.292389] [] rockchip_gem_create_object+0x6c/0x2ec > [ 31.298910] [] > rockchip_gem_create_with_handle+0x38/0x10c > [ 31.305868] [] rockchip_gem_create_ioctl+0x38/0x50 > [ 31.312221] [] drm_ioctl+0x2bc/0x438 > [ 31.317359] [] drm_compat_ioctl+0x3c/0x70 > [ 31.322935] [] compat_SyS_ioctl+0x134/0x1048 > [ 31.328766] [] __sys_trace_return+0x0/0x4 Hi Jeffy, I'm not suggesting this doesn't happen, I believe you :-). I'd really like to know *why* it happens. Are you sure that unbind has completely finished before this trace occurs? Perhaps this is results from a race between unbind and gem allocate? Sean > > > Sean > > > > > > > > Signed-off-by: Jeffy Chen > > > --- > > > > > > Changes in v3: > > > Address Daniel Vetter 's comments. > > > Update commit message. > > > > > > Changes in v2: None > > > > > > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > > > index df9e570..205a3dc 100644 > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > > > @@ -184,6 +184,9 @@ static int rockchip_gem_alloc_buf(struct rockchip_gem_object *rk_obj, > > > struct drm_device *drm = obj->dev; > > > struct rockchip_drm_private *private = drm->dev_private; > > > > > > + if (!private) > > > + return -ENODEV; > > > + > > > if (private->domain) > > > return rockchip_gem_alloc_iommu(rk_obj, alloc_kmap); > > > else > > > @@ -208,6 +211,11 @@ static void rockchip_gem_free_dma(struct rockchip_gem_object *rk_obj) > > > > > > static void rockchip_gem_free_buf(struct rockchip_gem_object *rk_obj) > > > { > > > + struct drm_device *drm = rk_obj->base.dev; > > > + > > > + if (!drm->dev_private) > > > + return; > > > + > > > if (rk_obj->pages) > > > rockchip_gem_free_iommu(rk_obj); > > > else > > > -- > > > 2.1.4 > > > > > > -- Sean Paul, Software Engineer, Google / Chromium OS