public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: David Brownell <david-b@pacbell.net>, linux-mtd@lists.infradead.org
Subject: RE: [PATCH] Fix memory leak in mtd_dataflash
Date: Wed, 14 Oct 2009 11:07:48 +0300	[thread overview]
Message-ID: <1255507668.32489.115.camel@localhost> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE190901DB7E55@mi8nycmail19.Mi8.com>

On Sun, 2009-10-11 at 16:49 -0400, H Hartley Sweeten wrote:
> On Sunday, October 11, 2009 6:10 AM, Artem Bityutskiy wrote:
> > On Wed, 2009-10-07 at 17:08 -0400, H Hartley Sweeten wrote:
> >> Fix a potential memory leak in mtd_dataflash driver.
> >> 
> >> The private data that is allocated when registering a DataFlash
> >> device with the MTD subsystem is not released if an error occurs
> >> when add_mtd_partitions() or add_mtd_device() is called.  Fix this
> >> by adding an error path.  The memory is already released during a
> >> remove.
> >> 
> >> Also, add a dev_set_drvdata(&spi->dev, NULL) before the kfree() so
> >> that the spi device does not reference invalid data.
> >> 
> >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> >> Cc: David Brownell <david-b@pacbell.net>
> >> Cc: linux-mtd@lists.infradead.org
> >> 
> >> ---
> >> 
> >> diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c
> >> index 93e3627..1981740 100644
> >> --- a/drivers/mtd/devices/mtd_dataflash.c
> >> +++ b/drivers/mtd/devices/mtd_dataflash.c
> >> @@ -636,6 +636,7 @@ add_dataflash_otp(struct spi_device *spi, char *name,
> >>  	struct mtd_info			*device;
> >>  	struct flash_platform_data	*pdata = spi->dev.platform_data;
> >>  	char				*otp_tag = "";
> >> +	int				err = 0;
> >>  
> >>  	priv = kzalloc(sizeof *priv, GFP_KERNEL);
> >>  	if (!priv)
> >> @@ -693,13 +694,23 @@ add_dataflash_otp(struct spi_device *spi, char *name,
> >>  
> >>  		if (nr_parts > 0) {
> >>  			priv->partitioned = 1;
> >> -			return add_mtd_partitions(device, parts, nr_parts);
> >> +			err = add_mtd_partitions(device, parts, nr_parts);
> >> +			goto out;
> >>  		}
> >>  	} else if (pdata && pdata->nr_parts)
> >>  		dev_warn(&spi->dev, "ignoring %d default partitions on %s\n",
> >>  				pdata->nr_parts, device->name);
> >>  
> >> -	return add_mtd_device(device) == 1 ? -ENODEV : 0;
> >> +	if (add_mtd_device(device) == 1)
> >> +		err = -ENODEV;
> >
> > But if you fail here, you should also call del_mtd_partitions(), right?
> 
> Not as I understand it.
> 
> If the device has partitions (mtd_has_partitions), and the subsystem can
> determine what they are, add_mtd_partitions is called to add those partitions.
> The only way the code gets to add_mtd_device is if mtd_has_partitions returns
> false or the number of partitions cannot be determined.  In that case the entire
> device is added.  So calling del_mtd_partitions in that case is not valid.
> 
> Did I overlook something?

Right. I've applied it to my l2-mtd-2.6 tree.


-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

      reply	other threads:[~2009-10-14  8:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-07 21:08 [PATCH] Fix memory leak in mtd_dataflash H Hartley Sweeten
2009-10-11 13:09 ` Artem Bityutskiy
2009-10-11 20:49   ` H Hartley Sweeten
2009-10-14  8:07     ` Artem Bityutskiy [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=1255507668.32489.115.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=david-b@pacbell.net \
    --cc=hartleys@visionengravers.com \
    --cc=linux-mtd@lists.infradead.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