From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Wen Yang <wen.yang99@zte.com.cn>
Cc: wang.yi59@zte.com.cn,
"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [PATCH v2 01/15] ARM: actions: fix a leaked reference by adding missing of_node_put
Date: Tue, 5 Mar 2019 11:40:48 +0000 [thread overview]
Message-ID: <20190305114048.egpbeddy4pqbwl5b@shell.armlinux.org.uk> (raw)
In-Reply-To: <1551785646-46173-1-git-send-email-wen.yang99@zte.com.cn>
On Tue, Mar 05, 2019 at 07:33:52PM +0800, Wen Yang wrote:
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./arch/arm/mach-actions/platsmp.c:112:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 103, but without a corresponding object release within this function.
> ./arch/arm/mach-actions/platsmp.c:124:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 115, but without a corresponding object release within this function.
> ./arch/arm/mach-actions/platsmp.c:137:3-9: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 128, but without a corresponding object release within this function.
I question this. Your reasoning is that the node is no longer used
so the reference count needs to be put.
However, in all these cases, data is read from the nodes properties
and the device remains in-use for the life of the kernel. There is
a big difference here.
With normal drivers, each device is bound to their associated device
node associated with the device. When the device node goes away, then
the corresponding device goes away too, which causes the driver to be
unbound from the device.
However, there is another class of "driver" which are the ones below,
where they are "permanent" devices. These can never go away, even if
the device node refcount hits zero and the device node is freed - the
device is still present and in-use in the system. So, having the
device node refcount hit zero is actually a bug: what that's saying
is the system device (eg, SCU) has gone away. If you somehow were to
remove the SCU from the system, you'd end up severing the connection
between the CPU cores and the rest of the system - obviously resulting
in a dead system!
So, what is the point of dropping these refcounts for devices that can
never go away - and thus their associated device_node should also never
go away?
>
> Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
> Cc: "Andreas Färber" <afaerber@suse.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v2->v1: add a missing space between "adding" and "missing"
>
> arch/arm/mach-actions/platsmp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-actions/platsmp.c b/arch/arm/mach-actions/platsmp.c
> index 4fd479c..1a8e078 100644
> --- a/arch/arm/mach-actions/platsmp.c
> +++ b/arch/arm/mach-actions/platsmp.c
> @@ -107,6 +107,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
> }
>
> timer_base_addr = of_iomap(node, 0);
> + of_node_put(node);
> if (!timer_base_addr) {
> pr_err("%s: could not map timer registers\n", __func__);
> return;
> @@ -119,6 +120,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
> }
>
> sps_base_addr = of_iomap(node, 0);
> + of_node_put(node);
> if (!sps_base_addr) {
> pr_err("%s: could not map sps registers\n", __func__);
> return;
> @@ -132,6 +134,7 @@ static void __init s500_smp_prepare_cpus(unsigned int max_cpus)
> }
>
> scu_base_addr = of_iomap(node, 0);
> + of_node_put(node);
> if (!scu_base_addr) {
> pr_err("%s: could not map scu registers\n", __func__);
> return;
> --
> 2.9.5
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-05 11:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 11:33 [PATCH v2 01/15] ARM: actions: fix a leaked reference by adding missing of_node_put Wen Yang
2019-03-05 11:33 ` [PATCH v2 02/15] ARM: bcm: " Wen Yang
2019-03-05 17:24 ` Ray Jui
2019-03-08 18:50 ` Florian Fainelli
2019-03-05 11:33 ` [PATCH v2 03/15] ARM: exynos: " Wen Yang
2019-03-19 20:39 ` Krzysztof Kozlowski
2019-03-05 11:33 ` [PATCH v2 04/15] ARM: hisi: " Wen Yang
2019-04-05 11:26 ` Markus Elfring
2019-03-05 11:33 ` [PATCH v2 05/15] ARM: imx51: " Wen Yang
2019-03-06 2:58 ` Shawn Guo
2019-03-05 11:33 ` [PATCH v2 06/15] arm: npcm: " Wen Yang
2019-03-06 12:02 ` Avi Fishman
2019-03-05 11:33 ` [PATCH v2 07/15] ARM: rockchip: " Wen Yang
2019-04-23 17:48 ` Heiko Stuebner
2019-03-05 11:33 ` [PATCH v2 08/15] ARM: shmobile: " Wen Yang
2019-03-08 12:07 ` Simon Horman
2019-03-05 11:34 ` [PATCH v2 09/15] ARM: socfpga: " Wen Yang
2019-03-05 11:34 ` [PATCH v2 10/15] ARM: sunxi: " Wen Yang
2019-03-05 11:59 ` maxime.ripard
2019-03-05 11:34 ` [PATCH v2 11/15] ARM: versatile: " Wen Yang
2019-03-05 11:34 ` [PATCH v2 12/15] ARM: vexpress: " Wen Yang
2019-03-05 11:39 ` Sudeep Holla
2019-03-05 11:34 ` [PATCH v2 13/15] ARM: zynq: " Wen Yang
2019-03-05 11:34 ` [PATCH v2 14/15] arm64: cpu_ops: " Wen Yang
2019-04-01 15:37 ` Will Deacon
[not found] ` <201904031356099956278@zte.com.cn>
2019-04-03 12:44 ` 答复: Re: [PATCH v2 14/15] arm64: cpu_ops: fix a leaked reference byadding " Will Deacon
2019-03-05 11:34 ` [PATCH v2 15/15] ARM: axxia: fix a leaked reference by adding " Wen Yang
2019-03-05 11:40 ` Russell King - ARM Linux admin [this message]
2019-03-09 2:17 ` [PATCH v2 01/15] ARM: actions: " Manivannan Sadhasivam
2019-03-09 8:14 ` Russell King - ARM Linux admin
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=20190305114048.egpbeddy4pqbwl5b@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=afaerber@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=wang.yi59@zte.com.cn \
--cc=wen.yang99@zte.com.cn \
/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;
as well as URLs for NNTP newsgroup(s).