From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [PATCH] drm/exynos: fix kernel panic issue at drm releasing Date: Tue, 05 Jan 2016 21:30:10 +0900 Message-ID: <568BB752.7050603@samsung.com> References: <1450948214-14688-1-git-send-email-inki.dae@samsung.com> <568A5E3A.8090601@samsung.com> <568BA138.3050504@samsung.com> <20160105110811.GB8076@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-reply-to: <20160105110811.GB8076@phenom.ffwll.local> Sender: linux-samsung-soc-owner@vger.kernel.org To: Daniel Vetter Cc: Daniel Stone , linux-samsung-soc , dri-devel , Rob Clark List-Id: dri-devel@lists.freedesktop.org + Rob Clark, Hi Daniel and Rob, 2016=EB=85=84 01=EC=9B=94 05=EC=9D=BC 20:08=EC=97=90 Daniel Vetter =EC=9D= =B4(=EA=B0=80) =EC=93=B4 =EA=B8=80: > On Tue, Jan 05, 2016 at 07:55:52PM +0900, Inki Dae wrote: >> Hi Daniel, >> >> 2016=EB=85=84 01=EC=9B=94 05=EC=9D=BC 05:24=EC=97=90 Daniel Stone =EC= =9D=B4(=EA=B0=80) =EC=93=B4 =EA=B8=80: >>> Hi Inki, >>> >>> On 4 January 2016 at 12:57, Inki Dae wrote: >>>> 2015=EB=85=84 12=EC=9B=94 24=EC=9D=BC 22:32=EC=97=90 Daniel Stone = =EC=9D=B4(=EA=B0=80) =EC=93=B4 =EA=B8=80: >>>>> On 24 December 2015 at 09:10, Inki Dae wro= te: >>>>>> +void exynos_drm_crtc_cancel_page_flip(struct drm_crtc *crtc) >>>>>> +{ >>>>>> + struct exynos_drm_crtc *exynos_crtc =3D to_exynos_crtc(c= rtc); >>>>>> + unsigned long flags; >>>>>> + >>>>>> + spin_lock_irqsave(&crtc->dev->event_lock, flags); >>>>>> + exynos_crtc->event =3D NULL; >>>>>> + spin_unlock_irqrestore(&crtc->dev->event_lock, flags); >>>>>> +} >>>>> >>>>> This will leak the event and event space; you should call >>>>> event->base.destroy() here. With that fixed: >>>> >>>> Right. we don't use exynos specific page flip function anymore whi= ch managed the event as a list so that the event objects can be freed b= y postclose callback. >>>> Anyway, would it be better for event->base.destory() to be called = between spin lock/unlock? >>> >>> You must increment event->base.file_priv->event_space (see >>> drm_atomic.c:destroy_vblank_event), as well as calling >> >> Reasonable to me. Seems other DRM drivers don't increment event_spac= e. >> >>> event->base.destroy (see drm_fops.c:drm_read) underneath event_lock= , >>> yes. >> >> In addition, only event objects belonging to the request process sho= uld be destroyed. >=20 > Just random comment out of the far left field, but robclark had a bun= ch of > patches to clean up all that event alloc/cleanup code a bit and extra= ct it > into core functions. Might be good to ping him on irc to figure out w= here > that series is and whether you could take it over. Good news. I'll try to ping him on irc. To Rob, Can you let me know where your bunch of patches are? I'd like to look i= nto the patches. I'd planned to have pull request so that this patch ca= n go to 4.4. As you had already relevant patch set maybe, we would need to check whe= ther my patch can be replaced with your patch set or there is any corne= r case. Thanks, Inki Dae >=20 > Cheers, Daniel >=20