From: Hans de Goede <hdegoede@redhat.com>
To: Nishka Dasgupta <nishkadg.linux@gmail.com>,
axboe@kernel.dk, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org,
devicetree <devicetree@vger.kernel.org>
Subject: for_each_child_of_node semantics are broken (was [PATCH] ata: libahci_platform: Add of_node_put() before loop exit)
Date: Thu, 15 Aug 2019 10:53:06 +0200 [thread overview]
Message-ID: <a469ccae-0b34-8a8f-376c-7cd176fd05bf@redhat.com> (raw)
In-Reply-To: <20190815060014.2191-1-nishkadg.linux@gmail.com>
Hi Nishka,
On 15-08-19 08:00, Nishka Dasgupta wrote:
> Each iteration of for_each_child_of_node puts the previous node, but
> in the case of a goto from the middle of the loop, there is no put,
> thus causing a memory leak. Add an of_node_put before three such goto
> statements.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
Thank you for your patch.
I do not like doing an of_node_put for something which we did not
explicitly of_node_get. So I was thinking about maybe replacing the
goto-s with a break.
But even if we put a break in the for_each_child_of_node loop,
we still leak the reference. Which IMHO means that the semantics of
the for_each_child_of_node helper are broken, this certainly violates
the principle of least surprise which one would expect of a good API.
I see that there are quite a few callers of this function:
[hans@shalem linux]$ ack -l for_each_child_of_node drivers | wc -l
194
And doing a manual check of these (with the intend to stop after
a couple) I already find something suspicious in the second file
ack -l returns:
for_each_child_of_node(parent, dn) {
pnv_php_detach_device_nodes(dn);
of_node_put(dn);
refcount = kref_read(&dn->kobj.kref);
if (refcount != 1)
pr_warn("Invalid refcount %d on <%pOF>\n",
refcount, dn);
of_detach_node(dn);
}
note this does an of_node_put itself and then continues iterating,
now this function looks pretty magical to me, so it might be fine...
4th file inspected, same issue with error returns as the libahci_platform
code, see drivers/pci/controller/pci-tegra.c: tegra_pcie_parse_dt
also should that function not do a a get on the node since it stores
it in rp->np if things do succeed ?
5th file: drivers/char/rtc.c:
for_each_node_by_name(ebus_dp, "ebus") {
struct device_node *dp;
for_each_child_of_node(ebus_dp, dp) {
if (of_node_name_eq(dp, "rtc")) {
op = of_find_device_by_node(dp);
if (op) {
rtc_port = op->resource[0].start;
rtc_irq = op->irqs[0];
goto found;
}
}
}
}
Also a leak AFAICT.
10th file: drivers/phy/phy-core.c:
for_each_child_of_node(phy_provider->children, child)
if (child == node)
return phy_provider;
Another leak...
I'm going to stop now because this just aint funny, but I do believe this
nicely illustrates how for_each_child_of_node() is ridiculously hard to use
correct.
Regards,
Hans
> ---
> drivers/ata/libahci_platform.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
> index 9e9583a6bba9..e742780950de 100644
> --- a/drivers/ata/libahci_platform.c
> +++ b/drivers/ata/libahci_platform.c
> @@ -497,6 +497,7 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
>
> if (of_property_read_u32(child, "reg", &port)) {
> rc = -EINVAL;
> + of_node_put(child);
> goto err_out;
> }
>
> @@ -514,14 +515,18 @@ struct ahci_host_priv *ahci_platform_get_resources(struct platform_device *pdev,
> if (port_dev) {
> rc = ahci_platform_get_regulator(hpriv, port,
> &port_dev->dev);
> - if (rc == -EPROBE_DEFER)
> + if (rc == -EPROBE_DEFER) {
> + of_node_put(child);
> goto err_out;
> + }
> }
> #endif
>
> rc = ahci_platform_get_phy(hpriv, port, dev, child);
> - if (rc)
> + if (rc) {
> + of_node_put(child);
> goto err_out;
> + }
>
> enabled_ports++;
> }
>
next prev parent reply other threads:[~2019-08-15 8:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-15 6:00 [PATCH] ata: libahci_platform: Add of_node_put() before loop exit Nishka Dasgupta
2019-08-15 8:53 ` Hans de Goede [this message]
2019-08-15 8:55 ` Hans de Goede
2019-09-19 18:17 ` Markus Elfring
2019-09-22 15:07 ` Markus Elfring
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=a469ccae-0b34-8a8f-376c-7cd176fd05bf@redhat.com \
--to=hdegoede@redhat.com \
--cc=axboe@kernel.dk \
--cc=devicetree@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nishkadg.linux@gmail.com \
/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).