All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/9] pci: mvebu: fix memory leaks and refcount leaks
Date: Fri, 9 Oct 2015 17:07:10 +0200	[thread overview]
Message-ID: <20151009150710.GJ14688@lunn.ch> (raw)
In-Reply-To: <20151009165240.3ba17ece@free-electrons.com>

On Fri, Oct 09, 2015 at 04:52:40PM +0200, Thomas Petazzoni wrote:
> Russell,
> 
> On Sat, 03 Oct 2015 19:13:02 +0100, Russell King wrote:
> 
> > +	ret = devm_add_action(dev, mvebu_pcie_port_clk_put, port);
> 
> I didn't know about devm_add_action(). Definitely very useful for such
> situations.

I was also surprised by this. Nice.
 
> > @@ -1052,10 +1086,12 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
> >  		struct mvebu_pcie_port *port = &pcie->ports[i];
> >  
> >  		ret = mvebu_pcie_parse_port(pcie, port, child);
> > -		if (ret < 0)
> > +		if (ret < 0) {
> > +			of_node_put(child);
> >  			return ret;
> > -		else if (ret == 0)
> > +		} else if (ret == 0) {
> >  			continue;
> > +		}
> 
> This is not trivial. If I understand correctly,
> for_each_available_child_of_node() will automatically release the
> reference on the previous node and take the reference on the new one
> before entering the loop code. So in the skipping case, we don't need
> to release the reference as it will be done by the next iteration of
> the loop, but in the error case, since we are unexpectedly breaking the
> loop, we need to do it manually.
> 
> The sort of tricky thing that should be documented near
> for_each_child_of_node(), since I believe a lot of code gets this
> wrong.

Sounds like a good candidate for a coccinelle script. Maybe you could
ask Julia Lawall?

    Andrew

WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/9] pci: mvebu: fix memory leaks and refcount leaks
Date: Fri, 9 Oct 2015 17:07:10 +0200	[thread overview]
Message-ID: <20151009150710.GJ14688@lunn.ch> (raw)
In-Reply-To: <20151009165240.3ba17ece@free-electrons.com>

On Fri, Oct 09, 2015 at 04:52:40PM +0200, Thomas Petazzoni wrote:
> Russell,
> 
> On Sat, 03 Oct 2015 19:13:02 +0100, Russell King wrote:
> 
> > +	ret = devm_add_action(dev, mvebu_pcie_port_clk_put, port);
> 
> I didn't know about devm_add_action(). Definitely very useful for such
> situations.

I was also surprised by this. Nice.
 
> > @@ -1052,10 +1086,12 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
> >  		struct mvebu_pcie_port *port = &pcie->ports[i];
> >  
> >  		ret = mvebu_pcie_parse_port(pcie, port, child);
> > -		if (ret < 0)
> > +		if (ret < 0) {
> > +			of_node_put(child);
> >  			return ret;
> > -		else if (ret == 0)
> > +		} else if (ret == 0) {
> >  			continue;
> > +		}
> 
> This is not trivial. If I understand correctly,
> for_each_available_child_of_node() will automatically release the
> reference on the previous node and take the reference on the new one
> before entering the loop code. So in the skipping case, we don't need
> to release the reference as it will be done by the next iteration of
> the loop, but in the error case, since we are unexpectedly breaking the
> loop, we need to do it manually.
> 
> The sort of tricky thing that should be documented near
> for_each_child_of_node(), since I believe a lot of code gets this
> wrong.

Sounds like a good candidate for a coccinelle script. Maybe you could
ask Julia Lawall?

    Andrew

  reply	other threads:[~2015-10-09 15:07 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-03 18:12 [PATCH 0/9] Further mvebu PCIe patches Russell King - ARM Linux
2015-10-03 18:12 ` Russell King - ARM Linux
2015-10-03 18:12 ` [PATCH 1/9] pci: mvebu: move port parsing and resource claiming to separate function Russell King
2015-10-03 18:12   ` Russell King
2015-10-03 18:13 ` [PATCH 2/9] pci: mvebu: fix memory leaks and refcount leaks Russell King
2015-10-03 18:13   ` Russell King
2015-10-09 14:52   ` Thomas Petazzoni
2015-10-09 14:52     ` Thomas Petazzoni
2015-10-09 15:07     ` Andrew Lunn [this message]
2015-10-09 15:07       ` Andrew Lunn
2015-10-09 15:14       ` Thomas Petazzoni
2015-10-09 15:14         ` Thomas Petazzoni
2015-10-09 15:35         ` Russell King - ARM Linux
2015-10-09 15:35           ` Russell King - ARM Linux
2015-10-09 16:39           ` Julia Lawall
2015-10-09 16:39             ` Julia Lawall
2015-10-09 16:49             ` Russell King - ARM Linux
2015-10-09 16:49               ` Russell King - ARM Linux
2015-10-09 15:54         ` Julia Lawall
2015-10-09 15:54           ` Julia Lawall
2015-10-09 15:07     ` Russell King - ARM Linux
2015-10-09 15:07       ` Russell King - ARM Linux
2015-10-03 18:13 ` [PATCH 3/9] pci: mvebu: split port parsing and resource claiming from port setup Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 4/9] pci: mvebu: use gpio_set_value_cansleep() Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 5/9] pci: mvebu: use devm_kcalloc() to allocate an array Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 6/9] pci: mvebu: use gpio_desc to carry around gpio Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 7/9] pci: mvebu: better implementation of clock/reset handling Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 8/9] pci: mvebu: add PCI Express root complex capability block Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 18:13 ` [PATCH 9/9] pci: mvebu: remove code restricting accesses to slot 0 Russell King
2015-10-03 18:13   ` Russell King
2015-10-03 19:00 ` [PATCH 0/9] Further mvebu PCIe patches Thomas Petazzoni
2015-10-03 19:00   ` Thomas Petazzoni
2015-10-05 21:05   ` Willy Tarreau
2015-10-05 21:05     ` Willy Tarreau
2015-10-08 23:19 ` Andrew Lunn
2015-10-08 23:19   ` Andrew Lunn
2015-10-09 15:18 ` Thomas Petazzoni
2015-10-09 15:18   ` Thomas Petazzoni
2015-10-09 16:27 ` Bjorn Helgaas
2015-10-09 16:27   ` Bjorn Helgaas

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=20151009150710.GJ14688@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=bhelgaas@google.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=thomas.petazzoni@free-electrons.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.