Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753472AbdDGGoa (ORCPT ); Fri, 7 Apr 2017 02:44:30 -0400 Received: from regular1.263xmail.com ([211.150.99.130]:57758 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752631AbdDGGoX (ORCPT ); Fri, 7 Apr 2017 02:44:23 -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: daniel@ffwll.ch X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: jeffy.chen@rock-chips.com X-UNIQUE-TAG: <636f4009ffbc62c63d3fc314c6874e63> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Message-ID: <58E73535.4000409@rock-chips.com> Date: Fri, 07 Apr 2017 14:44:05 +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: Daniel Vetter CC: Sean Paul , Douglas Anderson , Brian Norris , Linux Kernel Mailing List , dri-devel , Tomasz Figa , "open list:ARM/Rockchip SoC..." , Chris Zhong , "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> <20170406082612.qmwyfjr5uwcp3arr@phenom.ffwll.local> <58E621D7.3030205@rock-chips.com> In-Reply-To: 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: 1663 Lines: 47 Hi Daniel, On 04/07/2017 02:30 PM, Daniel Vetter wrote: > On Thu, Apr 6, 2017 at 1:09 PM, jeffy wrote: >> >> On 04/06/2017 04:26 PM, Daniel Vetter wrote: >>> >>> On Wed, Apr 05, 2017 at 12:28:40PM -0400, 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? >>> >>> >>> Yeah this is supposed to be impossible. If it isn't, we need to debug and >>> fix this properly. This smells like pretty bad duct-tape ... >> >> >> it looks like after unbind, the user space may still own drm dev fd, and >> could be able to call ioctl: >> lrwx------. 1 chronos chronos 64 Mar 15 12:53 28 -> /dev/dri/card1 (deleted) >> >> and the drm_unplug_dev may help it, maybe we should call it in unbind? or >> just break drm_ioctl when drm_dev not registered? > > Yes, by default unbind while userspace is running is totally broken in > drm. drm_unplug_dev would be the fix, but it's only used by udl and > not many use that. You might need to fix infrastructure up a bit. please check this patch: 9667071 New [v5,12/12] drm/drm_ioctl.c: Break ioctl when drm device not registered > > For normal module unload the module reference will prevent unloading. > So why exactly do you care about the unbind use-case? sometimes we use unbind/bind for testing ;) > -Daniel >