All of lore.kernel.org
 help / color / mirror / Atom feed
From: mingo@kernel.org (Ingo Molnar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: 8351/1: perf: fix memory leak on return
Date: Wed, 20 May 2015 13:57:05 +0200	[thread overview]
Message-ID: <20150520115705.GA5273@gmail.com> (raw)
In-Reply-To: <5559BAF7.70205@canonical.com>


* Colin Ian King <colin.king@canonical.com> wrote:

> On 16/05/15 08:09, Ingo Molnar wrote:
> > 
> > * Colin King <colin.king@canonical.com> wrote:
> > 
> >> From: Colin Ian King <colin.king@canonical.com>
> >>
> >> Recent commit 3b8786ff7a1b31645ae2c26a2ec32dbd42ac1094
> >> ("ARM: 8352/1: perf: Fix the pmu node name in warning message")
> >> introduced a memory leak of irqs on the "Don't bother with PPIs"
> >> return path. This was picked up by static analysis by cppcheck:
> >>
> >> [arch/arm/kernel/perf_event_cpu.c:315]: (error) Memory leak: irqs
> >>
> >> simpele fix is to free irqs when returning.
> >>
> >> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> >> ---
> >>  arch/arm/kernel/perf_event_cpu.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
> >> index 213919b..9e5b2a5 100644
> >> --- a/arch/arm/kernel/perf_event_cpu.c
> >> +++ b/arch/arm/kernel/perf_event_cpu.c
> >> @@ -311,8 +311,10 @@ static int of_pmu_irq_cfg(struct platform_device *pdev)
> >>  
> >>  	/* Don't bother with PPIs; they're already affine */
> >>  	irq = platform_get_irq(pdev, 0);
> >> -	if (irq >= 0 && irq_is_percpu(irq))
> >> +	if (irq >= 0 && irq_is_percpu(irq)) {
> >> +		kfree(irqs);
> >>  		return 0;
> >> +	}
> >>  
> >>  	for (i = 0; i < pdev->num_resources; ++i) {
> >>  		struct device_node *dn;
> > 
> > So returning from the middle of a function isn't very clean.
> > 
> > Also, why do we return 0 in an error case?
> 
> I believe that's explained in commit
> 338d9dd3e2aee00a9198e8bf6e7d535d3feeaf32 ("ARM: 8351/1: perf: don't warn
> about missing interrupt-affinity property for PPIs"):
> 
> "PPIs are affine by nature, so the interrupt-affinity property is not
>  used and therefore we shouldn't print a warning in its absence."

That should probably be mentioned in the fine code as well, to keep 
future generations from wondering.

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Colin Ian King <colin.king@canonical.com>
Cc: Will Deacon <will.deacon@arm.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Russell King <linux@arm.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ARM: 8351/1: perf: fix memory leak on return
Date: Wed, 20 May 2015 13:57:05 +0200	[thread overview]
Message-ID: <20150520115705.GA5273@gmail.com> (raw)
In-Reply-To: <5559BAF7.70205@canonical.com>


* Colin Ian King <colin.king@canonical.com> wrote:

> On 16/05/15 08:09, Ingo Molnar wrote:
> > 
> > * Colin King <colin.king@canonical.com> wrote:
> > 
> >> From: Colin Ian King <colin.king@canonical.com>
> >>
> >> Recent commit 3b8786ff7a1b31645ae2c26a2ec32dbd42ac1094
> >> ("ARM: 8352/1: perf: Fix the pmu node name in warning message")
> >> introduced a memory leak of irqs on the "Don't bother with PPIs"
> >> return path. This was picked up by static analysis by cppcheck:
> >>
> >> [arch/arm/kernel/perf_event_cpu.c:315]: (error) Memory leak: irqs
> >>
> >> simpele fix is to free irqs when returning.
> >>
> >> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> >> ---
> >>  arch/arm/kernel/perf_event_cpu.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
> >> index 213919b..9e5b2a5 100644
> >> --- a/arch/arm/kernel/perf_event_cpu.c
> >> +++ b/arch/arm/kernel/perf_event_cpu.c
> >> @@ -311,8 +311,10 @@ static int of_pmu_irq_cfg(struct platform_device *pdev)
> >>  
> >>  	/* Don't bother with PPIs; they're already affine */
> >>  	irq = platform_get_irq(pdev, 0);
> >> -	if (irq >= 0 && irq_is_percpu(irq))
> >> +	if (irq >= 0 && irq_is_percpu(irq)) {
> >> +		kfree(irqs);
> >>  		return 0;
> >> +	}
> >>  
> >>  	for (i = 0; i < pdev->num_resources; ++i) {
> >>  		struct device_node *dn;
> > 
> > So returning from the middle of a function isn't very clean.
> > 
> > Also, why do we return 0 in an error case?
> 
> I believe that's explained in commit
> 338d9dd3e2aee00a9198e8bf6e7d535d3feeaf32 ("ARM: 8351/1: perf: don't warn
> about missing interrupt-affinity property for PPIs"):
> 
> "PPIs are affine by nature, so the interrupt-affinity property is not
>  used and therefore we shouldn't print a warning in its absence."

That should probably be mentioned in the fine code as well, to keep 
future generations from wondering.

Thanks,

	Ingo

  reply	other threads:[~2015-05-20 11:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15 12:43 [PATCH] ARM: 8351/1: perf: fix memory leak on return Colin King
2015-05-15 12:43 ` Colin King
2015-05-16  7:09 ` Ingo Molnar
2015-05-16  7:09   ` Ingo Molnar
2015-05-18 10:12   ` Colin Ian King
2015-05-18 10:12     ` Colin Ian King
2015-05-20 11:57     ` Ingo Molnar [this message]
2015-05-20 11:57       ` Ingo Molnar

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=20150520115705.GA5273@gmail.com \
    --to=mingo@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.