All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Sean Paul <seanpaul@chromium.org>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>,
	dianders@chromium.org, briannorris@chromium.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	tfiga@chromium.org, linux-rockchip@lists.infradead.org,
	zyw@rock-chips.com, 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: Thu, 6 Apr 2017 10:26:12 +0200	[thread overview]
Message-ID: <20170406082612.qmwyfjr5uwcp3arr@phenom.ffwll.local> (raw)
In-Reply-To: <20170405162839.k6q4b3tpt6t2s3zm@art_vandelay>

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 ...
-Daniel

> 
> Sean
> 
> > 
> > Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> > ---
> > 
> > Changes in v3:
> > Address Daniel Vetter <daniel@ffwll.ch>'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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Sean Paul <seanpaul@chromium.org>
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>,
	linux-kernel@vger.kernel.org, briannorris@chromium.org,
	dianders@chromium.org, dri-devel@lists.freedesktop.org,
	tfiga@chromium.org, linux-rockchip@lists.infradead.org,
	zyw@rock-chips.com, 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: Thu, 6 Apr 2017 10:26:12 +0200	[thread overview]
Message-ID: <20170406082612.qmwyfjr5uwcp3arr@phenom.ffwll.local> (raw)
In-Reply-To: <20170405162839.k6q4b3tpt6t2s3zm@art_vandelay>

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 ...
-Daniel

> 
> Sean
> 
> > 
> > Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> > ---
> > 
> > Changes in v3:
> > Address Daniel Vetter <daniel@ffwll.ch>'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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: daniel@ffwll.ch (Daniel Vetter)
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: Thu, 6 Apr 2017 10:26:12 +0200	[thread overview]
Message-ID: <20170406082612.qmwyfjr5uwcp3arr@phenom.ffwll.local> (raw)
In-Reply-To: <20170405162839.k6q4b3tpt6t2s3zm@art_vandelay>

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 ...
-Daniel

> 
> Sean
> 
> > 
> > Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> > ---
> > 
> > Changes in v3:
> > Address Daniel Vetter <daniel@ffwll.ch>'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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  parent reply	other threads:[~2017-04-06  8:26 UTC|newest]

Thread overview: 50+ 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 [this message]
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
2017-04-07  6:44             ` jeffy
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=20170406082612.qmwyfjr5uwcp3arr@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=briannorris@chromium.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeffy.chen@rock-chips.com \
    --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.