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 (Артём Битюцкий)
prev parent 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