Re: [PATCH 1/5] drm/armada: fix leak of crtc structure

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Wed, Nov 29, 2017 at 03:03:09PM -0500, Sean Paul wrote:
> On Wed, Nov 29, 2017 at 07:16:43PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Nov 29, 2017 at 09:53:42AM -0500, Sean Paul wrote:
> > > On Wed, Nov 29, 2017 at 11:45:43AM +0000, Russell King wrote:
> > > > Fix the leak of the CRTC structure in the failure paths of
> > > > armada_drm_crtc_create().
> > > > 
> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > ---
> > > >  drivers/gpu/drm/armada/armada_crtc.c | 10 ++++++++--
> > > >  1 file changed, 8 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/armada/armada_crtc.c b/drivers/gpu/drm/armada/armada_crtc.c
> > > > index 2e065facdce7..844d488b6654 100644
> > > > --- a/drivers/gpu/drm/armada/armada_crtc.c
> > > > +++ b/drivers/gpu/drm/armada/armada_crtc.c
> > > > @@ -1246,11 +1246,14 @@ static int armada_drm_crtc_create(struct drm_device *drm, struct device *dev,
> > > >  	dcrtc->crtc.port = port;
> > > >  
> > > >  	primary = kzalloc(sizeof(*primary), GFP_KERNEL);
> > > > -	if (!primary)
> > > > +	if (!primary) {
> > > > +		kfree(dcrtc);
> > > >  		return -ENOMEM;
> > > > +	}
> > > >  
> > > >  	ret = armada_drm_plane_init(primary);
> > > >  	if (ret) {
> > > > +		kfree(dcrtc);
> > > >  		kfree(primary);
> > > >  		return ret;
> > > >  	}
> > > > @@ -1262,14 +1265,17 @@ static int armada_drm_crtc_create(struct drm_device *drm, struct device *dev,
> > > >  				       NULL,
> > > >  				       DRM_PLANE_TYPE_PRIMARY, NULL);
> > > >  	if (ret) {
> > > > +		kfree(dcrtc);
> > > >  		kfree(primary);
> > > >  		return ret;
> > > >  	}
> > > >  
> > > >  	ret = drm_crtc_init_with_planes(drm, &dcrtc->crtc, &primary->base, NULL,
> > > >  					&armada_crtc_funcs, NULL);
> > > > -	if (ret)
> > > > +	if (ret) {
> > > > +		kfree(dcrtc);
> > > >  		goto err_crtc_init;
> > > 
> > > The mixed use of cleaning up at every exit and the lone label is a bit messy and
> > > prone to bugs such as the one you're fixing. How about you label everything
> > > and then just clean up once?
> > 
> > It's not that simple - see alternative patch below.  How we clean
> > stuff up depends on how far through the initialisation we are, and
> > that doesn't lend itself to a sequential cleanup methodology.
> 
> It can be that simple, depending on how you setup your initialization sequence.
> For instance, if armada_plane_init did the allocation as well as
> universal_plane_init (like armada_overlay_plane_create already does), then you
> wouldn't need to worry about kfree(primary) at all.

Two problems with that:

1. The underlying plane structures for the primary and overlay planes
   are different.

2. the calls to drm_universal_plane_init() are rather different:

- primary:
        ret = drm_universal_plane_init(drm, &primary->base, 0,
                                       &armada_primary_plane_funcs,
                                       armada_primary_formats,
                                       ARRAY_SIZE(armada_primary_formats),
                                       NULL,
                                       DRM_PLANE_TYPE_PRIMARY, NULL);

- overlay:
        ret = drm_universal_plane_init(dev, &dplane->base.base, crtcs,
                                       &armada_ovl_plane_funcs,
                                       armada_ovl_formats,
                                       ARRAY_SIZE(armada_ovl_formats),
                                       NULL,
                                       DRM_PLANE_TYPE_OVERLAY, NULL);

Moving the drm_universal_plane_init() call into armada_drm_plane_init()
in a patch to fix a leak doesn't make sense - you're actually asking for
a massive rewrite of the code (I do have patches which I'm intending to
send after this series which do quite a lot of re-organisation of this
plane code, but I want to get the fixes sorted before I post that.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel