Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753869AbdDFCwM (ORCPT ); Wed, 5 Apr 2017 22:52:12 -0400 Received: from regular1.263xmail.com ([211.150.99.130]:56451 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752846AbdDFCvv (ORCPT ); Wed, 5 Apr 2017 22:51:51 -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: <1b0fd8b4d05e9e21b2cf1a3539096d91> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <58E5AC5F.5090303@rock-chips.com> Date: Thu, 06 Apr 2017 10:47:59 +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, 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 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> In-Reply-To: <20170405162839.k6q4b3tpt6t2s3zm@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: 2471 Lines: 74 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 > 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 >> >