Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] mc13783-regulator: fix a memory leak in mc13783_regulator_remove

0 views
Skip to first unread message

Axel Lin

unread,
Apr 18, 2010, 10:00:01 PM4/18/10
to
This patch fixes a memory leak by freeing priv in mc13783_regulator_remove

Signed-off-by: Axel Lin <axel...@gmail.com>
Cc: Sascha Hauer <s.h...@pengutronix.de>
Cc: Liam Girdwood <l...@slimlogic.co.uk>
Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
Cc: Samuel Ortiz <sa...@linux.intel.com>
---
drivers/regulator/mc13783-regulator.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/mc13783-regulator.c
b/drivers/regulator/mc13783-regulator.c
index a681f5e..ad036dd 100644
--- a/drivers/regulator/mc13783-regulator.c
+++ b/drivers/regulator/mc13783-regulator.c
@@ -618,9 +618,12 @@ static int __devexit
mc13783_regulator_remove(struct platform_device *pdev)
dev_get_platdata(&pdev->dev);
int i;

+ platform_set_drvdata(pdev, NULL);
+
for (i = 0; i < pdata->num_regulators; i++)
regulator_unregister(priv->regulators[i]);

+ kfree(priv);
return 0;
}

--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Liam Girdwood

unread,
Apr 19, 2010, 8:40:01 AM4/19/10
to
On Mon, 2010-04-19 at 09:58 +0800, Axel Lin wrote:
> This patch fixes a memory leak by freeing priv in mc13783_regulator_remove
>
> Signed-off-by: Axel Lin <axel...@gmail.com>
> Cc: Sascha Hauer <s.h...@pengutronix.de>
> Cc: Liam Girdwood <l...@slimlogic.co.uk>
> Cc: Mark Brown <bro...@opensource.wolfsonmicro.com>
> Cc: Samuel Ortiz <sa...@linux.intel.com>
> ---
> drivers/regulator/mc13783-regulator.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>

Applied.

Thanks

Liam

--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Mark Brown

unread,
Apr 19, 2010, 1:10:03 PM4/19/10
to
On Mon, Apr 19, 2010 at 09:58:02AM +0800, Axel Lin wrote:
> This patch fixes a memory leak by freeing priv in mc13783_regulator_remove

Acked-by: Mark Brown <bro...@opensource.wolfsonmicro.com>

but note that...

> + platform_set_drvdata(pdev, NULL);
> +

This is completely unrelated to what your description says (and is not
needed).

Axel Lin

unread,
Apr 20, 2010, 1:40:01 AM4/20/10
to
hi Mark,

2010/4/20 Mark Brown <bro...@opensource.wolfsonmicro.com>:


> On Mon, Apr 19, 2010 at 09:58:02AM +0800, Axel Lin wrote:
>> This patch fixes a memory leak by freeing priv in mc13783_regulator_remove
>
> Acked-by: Mark Brown <bro...@opensource.wolfsonmicro.com>
>
> but note that...
>
>> +       platform_set_drvdata(pdev, NULL);
>> +
>
> This is completely unrelated to what your description says (and is not
> needed).
>

In the probe function , the driver uses platform_set_drvdata(pdev,
priv) to store a pointer to the priv data structure.
To avoid leaving a dangling pointer behind, the driver should clear
the pointer to priv before freeing priv.

Regards,
Axel

Mark Brown

unread,
Apr 20, 2010, 12:40:01 PM4/20/10
to
On Tue, Apr 20, 2010 at 01:34:18PM +0800, Axel Lin wrote:
> 2010/4/20 Mark Brown <bro...@opensource.wolfsonmicro.com>:
> > On Mon, Apr 19, 2010 at 09:58:02AM +0800, Axel Lin wrote:

> >> +       platform_set_drvdata(pdev, NULL);
> >> +

> > This is completely unrelated to what your description says (and is not
> > needed).

> In the probe function , the driver uses platform_set_drvdata(pdev,
> priv) to store a pointer to the priv data structure.
> To avoid leaving a dangling pointer behind, the driver should clear
> the pointer to priv before freeing priv.

All of which is totally unrelated to the description of the patch. One
of the things that I do when I'm reviewing is look to see if the patch
does what the description says - unrelated changes are normally a red
flag that something is wrong and there are mistakes or unintended side
effects lurking in the code.

The dangling pointer isn't really a problem in any case; if a driver
is relying on the behaviour of the pointer between bindings it's in
trouble anyway since there aren't any guarantees about what happens.
See the recent discussion about the same issue for I2C.

0 new messages