public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>,
	catalin.marinas@arm.com, airlied@gmail.com,
	linux-kernel@vger.kernel.org, eric@anholt.net
Subject: Re: Memory leak issues in drm
Date: Thu, 23 Jul 2009 12:15:14 +1000	[thread overview]
Message-ID: <1248315314.8960.5.camel@t60prh> (raw)
In-Reply-To: <20090722170226.c5becf38.akpm@linux-foundation.org>

On Wed, 2009-07-22 at 17:02 -0700, Andrew Morton wrote:
> On Thu, 16 Jul 2009 12:39:18 +0530
> Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> 
> > On Thu, 2009-07-16 at 10:37 +0530, Jaswinder Singh Rajput wrote:
> > > On linus tree, while investigating kmemleak issues in drm :
> > > 
> > > unreferenced object 0xf571dea0 (size 32):
> > >   comm "Xorg", pid 1992, jiffies 4294703188
> > >   backtrace:
> > >     [<c1096655>] create_object+0x140/0x210
> > >     [<c10967f2>] kmemleak_alloc+0x25/0x4b
> > >     [<c1093b63>] __kmalloc+0xcb/0x153
> > >     [<c11ae939>] drm_setversion+0x154/0x1f6
> > >     [<c11ad0b1>] drm_ioctl+0x211/0x296
> > >     [<c10a2dc9>] vfs_ioctl+0x50/0x69
> > >     [<c10a3321>] do_vfs_ioctl+0x49b/0x4d5
> > >     [<c10a3387>] sys_ioctl+0x2c/0x45
> > >     [<c1002988>] sysenter_do_call+0x12/0x36
> > >     [<ffffffff>] 0xffffffff
> > > 
> > 
> > This fixes above memory leak in drm because it was allocating again on
> > dev->devname without freeing previous instance and more memory related
> > issues, hope this will be helpful:
> > 
> > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> > index 9b9ff46..b39ab86 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -96,25 +96,36 @@ int drm_setunique(struct drm_device *dev, void *data,
> 
> drm_setunique() is pretty crappy.  It has a number of places where it
> does some resource freeing and then a `return' and other places where
> it does the usual `goto out_free' thing.

Generally I try to avoid doing things to this function as it has great 
potential for breaking the X server badly, this definitely won't be a
fix I'd put in for this release.

I'll get some time to clean it up for drm-next.

Dave

> 
> I do think that converting this function to the usual
> single-return-statement model would simplify it and would reduce the
> chances of additional resource leaks being added in the future.
> 
> The basic pattern (which is applicable here) is:
> 
> foo()
> {
> 	if (!simple test)
> 		return -EFOO;
> 	if (!simple_test_2)
> 		return -EBAR;
> 
> 	foo = allocate_something();
> 
> 	if (test3)
> 		goto fail_foo;
> 
> 	bar = allocate_something_else();
> 
> 	if (test4)
> 		goto fail_bar;
> 
> 	...
> 
> 	return 0;		/* success */
> 
> fail_bar:
> 	deallocate(bar);
> fail_foo:
> 	deallocate(foo);
> 
> 	return err;
> }
> 
> >  	master->unique = kmalloc(master->unique_size, GFP_KERNEL);
> >  	if (!master->unique)
> >  		return -ENOMEM;
> > -	if (copy_from_user(master->unique, u->unique, master->unique_len))
> > +	if (copy_from_user(master->unique, u->unique, master->unique_len)) {
> > +		kfree(master->unique);
> > +		master->unique_len = 0;
> >  		return -EFAULT;
> > +	}
> >  
> >  	master->unique[master->unique_len] = '\0';
> >  
> > +	/* Free previous dev->devname, if exists */
> > +	if (dev->devname)
> > +		kfree(dev->devname);
> 
> kfree(NULL) is legal and will simplify and shorten the code here.
> 
> >  	dev->devname = kmalloc(strlen(dev->driver->pci_driver.name) +
> >  			       strlen(master->unique) + 2, GFP_KERNEL);
> > -	if (!dev->devname)
> > +	if (!dev->devname) {
> > +		kfree(master->unique);
> > +		master->unique_len = 0;
> >  		return -ENOMEM;
> > +	}
> >  
> >  	sprintf(dev->devname, "%s@%s", dev->driver->pci_driver.name,
> >  		master->unique);
> >  
> > -	/* Return error if the busid submitted doesn't match the device's actual
> > +	/*
> > +	 * Return error if the busid submitted doesn't match the device's actual
> >  	 * busid.
> >  	 */
> >  	ret = sscanf(master->unique, "PCI:%d:%d:%d", &bus, &slot, &func);
> >  	if (ret != 3)
> > -		return -EINVAL;
> > +		goto error;
> > +
> >  	domain = bus >> 8;
> >  	bus &= 0xff;
> >  
> > @@ -122,9 +133,15 @@ int drm_setunique(struct drm_device *dev, void *data,
> >  	    (bus != dev->pdev->bus->number) ||
> >  	    (slot != PCI_SLOT(dev->pdev->devfn)) ||
> >  	    (func != PCI_FUNC(dev->pdev->devfn)))
> > -		return -EINVAL;
> > +		goto error;
> >  
> >  	return 0;
> > +
> > +error:
> > +	kfree(dev->devname);
> > +	kfree(master->unique);
> > +
> > +	return -EINVAL;
> >  }
> >  
> >  static int drm_set_busid(struct drm_device *dev, struct drm_file *file_priv)
> > @@ -136,25 +153,35 @@ static int drm_set_busid(struct drm_device *dev, struct drm_file *file_priv)
> >  		return -EBUSY;
> >  
> >  	master->unique_len = 40;
> > -	master->unique_size = master->unique_len;
> > +	master->unique_size = master->unique_len + 1;
> >  	master->unique = kmalloc(master->unique_size, GFP_KERNEL);
> >  	if (master->unique == NULL)
> >  		return -ENOMEM;
> >  
> > -	len = snprintf(master->unique, master->unique_len, "pci:%04x:%02x:%02x.%d",
> > +	/*
> > +	 * Using sprintf as it will return number of characters
> > +	 * (not including the trailing '\0')
> > +	 */
> > +	len = sprintf(master->unique, "pci:%04x:%02x:%02x.%d",
> >  		       drm_get_pci_domain(dev),
> >  		       dev->pdev->bus->number,
> >  		       PCI_SLOT(dev->pdev->devfn),
> >  		       PCI_FUNC(dev->pdev->devfn));
> > -	if (len >= master->unique_len)
> > +	if (len > master->unique_len)
> >  		DRM_ERROR("buffer overflow");
> >  	else
> >  		master->unique_len = len;
> >  
> > +	/* Free previous dev->devname, if exists */
> > +	if (dev->devname)
> > +		kfree(dev->devname);
> 
> and here.
> 
> >  	dev->devname = kmalloc(strlen(dev->driver->pci_driver.name) +
> >  			       master->unique_len + 2, GFP_KERNEL);
> > -	if (dev->devname == NULL)
> > +	if (dev->devname == NULL) {
> > +		kfree(master->unique);
> > +		master->unique_len = 0;
> >  		return -ENOMEM;
> > +	}
> >  
> >  	sprintf(dev->devname, "%s@%s", dev->driver->pci_driver.name,
> >  		master->unique);
> > 


      reply	other threads:[~2009-07-23  2:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16  5:07 Memory leak issues in drm Jaswinder Singh Rajput
2009-07-16  7:09 ` Jaswinder Singh Rajput
2009-07-16  8:44   ` Catalin Marinas
2009-07-23  0:02   ` Andrew Morton
2009-07-23  2:15     ` Dave Airlie [this message]

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=1248315314.8960.5.camel@t60prh \
    --to=airlied@redhat.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=eric@anholt.net \
    --cc=jaswinder@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox