All of lore.kernel.org
 help / color / mirror / Atom feed
From: jeffy <jeffy.chen@rock-chips.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>,
	Douglas Anderson <dianders@chromium.org>,
	Brian Norris <briannorris@chromium.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Tomasz Figa <tfiga@chromium.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Chris Zhong <zyw@rock-chips.com>,
	"linux-arm-kernel@lists.infradead.org"
	<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
Date: Fri, 07 Apr 2017 14:44:05 +0800	[thread overview]
Message-ID: <58E73535.4000409@rock-chips.com> (raw)
In-Reply-To: <CAKMK7uEjyBwJKmZUnXZLZ_YzgajFMKNem-2Eoc80ZDXha-7o6g@mail.gmail.com>

Hi Daniel,

On 04/07/2017 02:30 PM, Daniel Vetter wrote:
> On Thu, Apr 6, 2017 at 1:09 PM, jeffy <jeffy.chen@rock-chips.com> 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
>

WARNING: multiple messages have this Message-ID (diff)
From: jeffy.chen@rock-chips.com (jeffy)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid
Date: Fri, 07 Apr 2017 14:44:05 +0800	[thread overview]
Message-ID: <58E73535.4000409@rock-chips.com> (raw)
In-Reply-To: <CAKMK7uEjyBwJKmZUnXZLZ_YzgajFMKNem-2Eoc80ZDXha-7o6g@mail.gmail.com>

Hi Daniel,

On 04/07/2017 02:30 PM, Daniel Vetter wrote:
> On Thu, Apr 6, 2017 at 1:09 PM, jeffy <jeffy.chen@rock-chips.com> 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
>

  reply	other threads:[~2017-04-07  6:44 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05  8:29 [PATCH v3 0/9] drm: rockchip: Fix rockchip drm unbind crash error Jeffy Chen
2017-04-05  8:29 ` Jeffy Chen
2017-04-05  8:29 ` [PATCH v3 1/9] drm: bridge: analogix: Detach panel when unbinding analogix dp Jeffy Chen
2017-04-06  6:54   ` Andrzej Hajda
2017-04-06  6:54     ` Andrzej Hajda
2017-04-05  8:29 ` [PATCH v3 2/9] drm: bridge: analogix: Unregister dp aux when unbinding Jeffy Chen
2017-04-06  7:11   ` Andrzej Hajda
2017-04-06  7:11     ` Andrzej Hajda
2017-04-06 12:18     ` jeffy
2017-04-05  8:29 ` [PATCH v3 3/9] drm: bridge: analogix: Destroy connector " Jeffy Chen
2017-04-06  7:19   ` Andrzej Hajda
2017-04-06  7:19     ` Andrzej Hajda
2017-04-06 12:20     ` jeffy
2017-04-05  8:29 ` [PATCH v3 4/9] drm/rockchip: cdn-dp: Don't try to release firmware when not loaded Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen
2017-04-05  8:29 ` [PATCH v3 5/9] drm/rockchip: vop: Enable pm domain before vop_initial Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen
2017-04-05  8:29 ` [PATCH v3 6/9] drm/rockchip: Reoder drm bind/unbind sequence Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen
2017-04-05  8:29 ` [PATCH v3 7/9] drm/rockchip: Shutdown all crtcs when unbinding drm Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen
2017-04-05  8:29 ` [PATCH v3 8/9] drm/rockchip: gem: Don't alloc/free gem buf when dev_private is invalid Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen
2017-04-05 16:28   ` Sean Paul
2017-04-05 16:28     ` Sean Paul
2017-04-05 16:28     ` Sean Paul
2017-04-06  2:47     ` jeffy
2017-04-06  2:47       ` jeffy
2017-04-06  2:47       ` jeffy
2017-04-06 12:26       ` Sean Paul
2017-04-06 12:26         ` Sean Paul
2017-04-06 12:26         ` Sean Paul
2017-04-06 12:54         ` jeffy
2017-04-06 12:54           ` jeffy
2017-04-06  8:26     ` Daniel Vetter
2017-04-06  8:26       ` Daniel Vetter
2017-04-06  8:26       ` Daniel Vetter
2017-04-06 11:09       ` jeffy
2017-04-06 11:09         ` jeffy
2017-04-07  6:30         ` Daniel Vetter
2017-04-07  6:30           ` Daniel Vetter
2017-04-07  6:30           ` Daniel Vetter
2017-04-07  6:44           ` jeffy [this message]
2017-04-07  6:44             ` jeffy
2017-04-07  7:15             ` Daniel Vetter
2017-04-07  7:15               ` Daniel Vetter
2017-04-07  7:15               ` Daniel Vetter
2017-04-05  8:29 ` [PATCH v3 9/9] drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding Jeffy Chen
2017-04-05  8:29   ` Jeffy Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58E73535.4000409@rock-chips.com \
    --to=jeffy.chen@rock-chips.com \
    --cc=briannorris@chromium.org \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=seanpaul@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=zyw@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.