[PATCH v4 0/3] arm: mvebu: fix resource leak

[PATCH v4 0/3] arm: mvebu: fix resource leak

[Jisheng Zhang]

These patches try to fix resource leak by adding missing of_node_put(),
iounmap or using devm_ioremap_resource() if available.

v4:
  - re-generate since Ezequiel's patches add DT support to the
mvebu-mbus driver

v3:
  - remove the clk patch since it's already taken by Mike
  - Add more commit log as suggested by Ezequiel Garcia

v2:
  - use devm_ioremap_resource() as suggested by Ezequiel Garcia
  - use gates_out instead of bail_out as suggested by Mike Turquette

Jisheng Zhang (3):
  arm: mvebu: add missing of_node_put() to fix reference leak
  bus: mvebu: add missing of_node_put() to fix reference leak
  pinctrl: mvebu: Convert to use devm_ioremap_resource

 arch/arm/mach-mvebu/coherency.c         |  8 +++++++-
 arch/arm/mach-mvebu/platsmp.c           |  1 +
 arch/arm/mach-mvebu/pmsu.c              |  1 +
 arch/arm/mach-mvebu/system-controller.c |  1 +
 drivers/bus/mvebu-mbus.c                | 27 ++++++++++++++++++++-------
 drivers/pinctrl/mvebu/pinctrl-mvebu.c   | 11 +++++------
 6 files changed, 35 insertions(+), 14 deletions(-)

-- 
1.8.4.rc3

[PATCH v4 1/3] arm: mvebu: add missing of_node_put() to fix reference leak

[Jisheng Zhang]

Add of_node_put to properly decrement the refcount when we are
done using a given node.

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 arch/arm/mach-mvebu/coherency.c         | 8 +++++++-
 arch/arm/mach-mvebu/platsmp.c           | 1 +
 arch/arm/mach-mvebu/pmsu.c              | 1 +
 arch/arm/mach-mvebu/system-controller.c | 1 +
 4 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 4c24303..58adf2f 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -140,6 +140,7 @@ int __init coherency_init(void)
 		coherency_base = of_iomap(np, 0);
 		coherency_cpu_base = of_iomap(np, 1);
 		set_cpu_coherent(cpu_logical_map(smp_processor_id()), 0);
+		of_node_put(np);
 	}
 
 	return 0;
@@ -147,9 +148,14 @@ int __init coherency_init(void)
 
 static int __init coherency_late_init(void)
 {
-	if (of_find_matching_node(NULL, of_coherency_table))
+	struct device_node *np;
+
+	np = of_find_matching_node(NULL, of_coherency_table);
+	if (np) {
 		bus_register_notifier(&platform_bus_type,
 				      &mvebu_hwcc_platform_nb);
+		of_node_put(np);
+	}
 	return 0;
 }
 
diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
index 4f960f0..5624a8f 100644
--- a/arch/arm/mach-mvebu/platsmp.c
+++ b/arch/arm/mach-mvebu/platsmp.c
@@ -118,6 +118,7 @@ void __init armada_xp_smp_prepare_cpus(unsigned int max_cpus)
 		panic("Cannot find 'marvell,bootrom' compatible node");
 
 	err = of_address_to_resource(node, 0, &res);
+	of_node_put(node);
 	if (err < 0)
 		panic("Cannot get 'bootrom' node address");
 
diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
index 3cc4bef..27fc4f0 100644
--- a/arch/arm/mach-mvebu/pmsu.c
+++ b/arch/arm/mach-mvebu/pmsu.c
@@ -67,6 +67,7 @@ int __init armada_370_xp_pmsu_init(void)
 		pr_info("Initializing Power Management Service Unit\n");
 		pmsu_mp_base = of_iomap(np, 0);
 		pmsu_reset_base = of_iomap(np, 1);
+		of_node_put(np);
 	}
 
 	return 0;
diff --git a/arch/arm/mach-mvebu/system-controller.c b/arch/arm/mach-mvebu/system-controller.c
index f875124..5175083c 100644
--- a/arch/arm/mach-mvebu/system-controller.c
+++ b/arch/arm/mach-mvebu/system-controller.c
@@ -98,6 +98,7 @@ static int __init mvebu_system_controller_init(void)
 		BUG_ON(!match);
 		system_controller_base = of_iomap(np, 0);
 		mvebu_sc = (struct mvebu_system_controller *)match->data;
+		of_node_put(np);
 	}
 
 	return 0;
-- 
1.8.4.rc3

[PATCH v4 2/3] bus: mvebu: add missing of_node_put() to fix reference leak

[Jisheng Zhang]

Add of_node_put to properly decrement the refcount when we are
done using a given node.

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/bus/mvebu-mbus.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 19ab6ff..a7c12fb 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -701,6 +701,7 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 					 size_t sdramwins_size)
 {
 	int win;
+	struct device_node *np;
 
 	mbus->mbuswins_base = ioremap(mbuswins_phys_base, mbuswins_size);
 	if (!mbus->mbuswins_base)
@@ -712,8 +713,11 @@ static int __init mvebu_mbus_common_init(struct mvebu_mbus_state *mbus,
 		return -ENOMEM;
 	}
 
-	if (of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric"))
+	np = of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric");
+	if (np) {
 		mbus->hw_io_coherency = 1;
+		of_node_put(np);
+	}
 
 	for (win = 0; win < mbus->soc->num_wins; win++)
 		mvebu_mbus_disable_window(mbus, win);
@@ -902,23 +906,27 @@ int __init mvebu_mbus_dt_init(void)
 	prop = of_get_property(np, "controller", NULL);
 	if (!prop) {
 		pr_err("required 'controller' property missing\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto np_out;
 	}
 
 	controller = of_find_node_by_phandle(be32_to_cpup(prop));
 	if (!controller) {
 		pr_err("could not find an 'mbus-controller' node\n");
-		return -ENODEV;
+		ret = -ENODEV;
+		goto np_out;
 	}
 
 	if (of_address_to_resource(controller, 0, &mbuswins_res)) {
 		pr_err("cannot get MBUS register address\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto phandle_out;
 	}
 
 	if (of_address_to_resource(controller, 1, &sdramwins_res)) {
 		pr_err("cannot get SDRAM register address\n");
-		return -EINVAL;
+		ret = -EINVAL;
+		goto phandle_out;
 	}
 
 	/* Get optional pcie-{mem,io}-aperture properties */
@@ -931,9 +939,14 @@ int __init mvebu_mbus_dt_init(void)
 				     sdramwins_res.start,
 				     resource_size(&sdramwins_res));
 	if (ret)
-		return ret;
+		goto phandle_out;
 
 	/* Setup statically declared windows in the DT */
-	return mbus_dt_setup(&mbus_state, np);
+	ret = mbus_dt_setup(&mbus_state, np);
+phandle_out:
+	of_node_put(controller);
+np_out:
+	of_node_put(np);
+	return ret;
 }
 #endif
-- 
1.8.4.rc3

[PATCH v4 3/3] pinctrl: mvebu: Convert to use devm_ioremap_resource

[Jisheng Zhang]

The resource mapped by of_iomap() isn't unmapped in error path. This
patch fix the resource leakage by using devm_ioremap_resource() instead
of of_iomap().

Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index bb7ddb1..1caa45f 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -579,7 +579,7 @@ static int mvebu_pinctrl_build_functions(struct platform_device *pdev,
 int mvebu_pinctrl_probe(struct platform_device *pdev)
 {
 	struct mvebu_pinctrl_soc_info *soc = dev_get_platdata(&pdev->dev);
-	struct device_node *np = pdev->dev.of_node;
+	struct resource *res;
 	struct mvebu_pinctrl *pctl;
 	void __iomem *base;
 	struct pinctrl_pin_desc *pdesc;
@@ -591,11 +591,10 @@ int mvebu_pinctrl_probe(struct platform_device *pdev)
 		return -EINVAL;
 	}
 
-	base = of_iomap(np, 0);
-	if (!base) {
-		dev_err(&pdev->dev, "unable to get base address\n");
-		return -ENODEV;
-	}
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
 
 	pctl = devm_kzalloc(&pdev->dev, sizeof(struct mvebu_pinctrl),
 			GFP_KERNEL);
-- 
1.8.4.rc3

[PATCH v4 0/3] arm: mvebu: fix resource leak

[Jason Cooper]

On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote:
> These patches try to fix resource leak by adding missing of_node_put(),
> iounmap or using devm_ioremap_resource() if available.
> 
> v4:
>   - re-generate since Ezequiel's patches add DT support to the
> mvebu-mbus driver

grrr.  I hate to ask this, but can you please rebase patches 1 and 2
against mvebu/fixes-non-critical?  No need to add back in the mvebu-mbus
hunk.

thx,

Jason.

[PATCH v4 3/3] pinctrl: mvebu: Convert to use devm_ioremap_resource

[Jason Cooper]

On Mon, Aug 26, 2013 at 07:36:58PM +0800, Jisheng Zhang wrote:
> The resource mapped by of_iomap() isn't unmapped in error path. This
> patch fix the resource leakage by using devm_ioremap_resource() instead
> of of_iomap().
> 
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> Reviewed-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c | 11 +++++------
>  1 file changed, 5 insertions(+), 6 deletions(-)

Acked-by: Jason Cooper <jason@lakedaemon.net>

thx,

Jason.

[PATCH v4 0/3] arm: mvebu: fix resource leak

[Jisheng Zhang]

Dear Jason,

On Mon, 26 Aug 2013 13:45:23 -0700
Jason Cooper <jason@lakedaemon.net> wrote:

> On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote:
> > These patches try to fix resource leak by adding missing of_node_put(),
> > iounmap or using devm_ioremap_resource() if available.
> > 
> > v4:
> >   - re-generate since Ezequiel's patches add DT support to the
> > mvebu-mbus driver
> 
> grrr.  I hate to ask this, but can you please rebase patches 1 and 2
> against mvebu/fixes-non-critical?  No need to add back in the mvebu-mbus
> hunk.

patch 1 also fixes one similar trivial issue introduced since 994c8c94b419e
"ARM: mvebu: Remove the harcoded BootROM window allocation" in linux-next tree

patch 2 is updated to fix similar trivial issue introduce since 6839cfa82f99
"bus: mvebu-mbus: Introduce device tree binding"

These two commits aren't included in mvebu/fixes-non-criticial yet. Could you
please give suggestion?

Thanks in advance,
Jisheng

[PATCH v4 0/3] arm: mvebu: fix resource leak

[Jason Cooper]

On Tue, Aug 27, 2013 at 11:01:20AM +0800, Jisheng Zhang wrote:
> Dear Jason,
> 
> On Mon, 26 Aug 2013 13:45:23 -0700
> Jason Cooper <jason@lakedaemon.net> wrote:
> 
> > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote:
> > > These patches try to fix resource leak by adding missing of_node_put(),
> > > iounmap or using devm_ioremap_resource() if available.
> > > 
> > > v4:
> > >   - re-generate since Ezequiel's patches add DT support to the
> > > mvebu-mbus driver
> > 
> > grrr.  I hate to ask this, but can you please rebase patches 1 and 2
> > against mvebu/fixes-non-critical?  No need to add back in the mvebu-mbus
> > hunk.
> 
> patch 1 also fixes one similar trivial issue introduced since 994c8c94b419e
> "ARM: mvebu: Remove the harcoded BootROM window allocation" in linux-next tree
> 
> patch 2 is updated to fix similar trivial issue introduce since 6839cfa82f99
> "bus: mvebu-mbus: Introduce device tree binding"
> 
> These two commits aren't included in mvebu/fixes-non-criticial yet. Could you
> please give suggestion?

Yes, that's correct.  We prefer to have patch submitters base off of a
mainline tag (eg v3.11-rc7).  conflicts between patchsets are then
caught and resolved when branches are merged.  If done correctly, the
merge resolution should be obvious in most cases.

The upstream maintainers _prefer_ to see those conflicts because it
gives them a better sense of who is tinkering in the same code-paths.

Trying to base patches off of disparate branches in order to
'pre-resolve' those conflicts creates unnecessary dependencies and
non-obvious merge-resolutions.

In this case I asked you base off of mvebu/fixes-non-critical because
that is where I will be applying them for queueing to arm-soc.  You
could also base off of v3.11-rc7, there's nothing in
mvebu/fixes-non-critical that should conflict with your changes.

thx,

Jason.

[PATCH v4 0/3] arm: mvebu: fix resource leak

[Jisheng Zhang]

Dear Jason,

On Mon, 26 Aug 2013 20:22:37 -0700
Jason Cooper <jason@lakedaemon.net> wrote:

> On Tue, Aug 27, 2013 at 11:01:20AM +0800, Jisheng Zhang wrote:
> > Dear Jason,
> > 
> > On Mon, 26 Aug 2013 13:45:23 -0700
> > Jason Cooper <jason@lakedaemon.net> wrote:
> > 
> > > On Mon, Aug 26, 2013 at 07:36:55PM +0800, Jisheng Zhang wrote:
> > > > These patches try to fix resource leak by adding missing
> > > > of_node_put(), iounmap or using devm_ioremap_resource() if available.
> > > > 
> > > > v4:
> > > >   - re-generate since Ezequiel's patches add DT support to the
> > > > mvebu-mbus driver
> > > 
> > > grrr.  I hate to ask this, but can you please rebase patches 1 and 2
> > > against mvebu/fixes-non-critical?  No need to add back in the mvebu-mbus
> > > hunk.
> > 
> > patch 1 also fixes one similar trivial issue introduced since
> > 994c8c94b419e "ARM: mvebu: Remove the harcoded BootROM window allocation"
> > in linux-next tree
> > 
> > patch 2 is updated to fix similar trivial issue introduce since
> > 6839cfa82f99 "bus: mvebu-mbus: Introduce device tree binding"
> > 
> > These two commits aren't included in mvebu/fixes-non-criticial yet. Could
> > you please give suggestion?
> 
> Yes, that's correct.  We prefer to have patch submitters base off of a
> mainline tag (eg v3.11-rc7).  conflicts between patchsets are then
> caught and resolved when branches are merged.  If done correctly, the
> merge resolution should be obvious in most cases.
> 
> The upstream maintainers _prefer_ to see those conflicts because it
> gives them a better sense of who is tinkering in the same code-paths.
> 
> Trying to base patches off of disparate branches in order to
> 'pre-resolve' those conflicts creates unnecessary dependencies and
> non-obvious merge-resolutions.
> 
> In this case I asked you base off of mvebu/fixes-non-critical because
> that is where I will be applying them for queueing to arm-soc.  You
> could also base off of v3.11-rc7, there's nothing in
> mvebu/fixes-non-critical that should conflict with your changes.
> 

Got it. Thanks very much for your excellent explanation.

Will do and send out patches latter.

Best Regards,
Jisheng