From: Robert Richter <robert.richter@amd.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
Paul Mundt <lethal@linux-sh.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 1/4] oprofile: Handle initialisation failure more gracefully
Date: Fri, 27 Aug 2010 14:43:44 +0200 [thread overview]
Message-ID: <20100827124344.GJ22783@erda.amd.com> (raw)
In-Reply-To: <442a16796990290ca3ebaaa3d0ab317e7b0a30a5.1282848651.git.matt@console-pimps.org>
On 26.08.10 15:09:16, Matt Fleming wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> The current implementation is not entirely safe in the case that
> oprofile_arch_init() fails. We need to make sure that we always call
> exit_driverfs() if we've called init_driverfs(). Also, avoid a potential
> double free when freeing 'counter_config', e.g. don't free
> 'counter_config' in both oprofile_arch_init() and oprofile_arch_exit().
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/oprofile/common.c | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> index 0691176..482779c 100644
> --- a/arch/arm/oprofile/common.c
> +++ b/arch/arm/oprofile/common.c
> @@ -275,10 +275,12 @@ out:
> return ret;
> }
>
> -static void exit_driverfs(void)
> +static void exit_driverfs(void)
> {
> - platform_device_unregister(oprofile_pdev);
> - platform_driver_unregister(&oprofile_driver);
> + if (!IS_ERR_OR_NULL(oprofile_pdev)) {
> + platform_device_unregister(oprofile_pdev);
> + platform_driver_unregister(&oprofile_driver);
> + }
The root cause that makes this check necessary is that
oprofile_arch_exit() is called though oprofile_arch_init() failed. We
should better fix this instead. I have to admit we will then have to
check all architectural implementations.
> }
> #else
> static int __init init_driverfs(void) { return 0; }
> @@ -363,10 +365,8 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> }
>
> ret = init_driverfs();
> - if (ret) {
> - kfree(counter_config);
We should not return from oprofile_arch_init() with allocated
resources if the function fails. To fix duplicate kfrees, we should
free it here and then set counter_config to NULL. It should also be
freed if for_each_possible_cpu() or op_name_from_perf_id() fails.
Also, the pointer should be NULLed after freeing in
oprofile_arch_exit(). There, we also don't need the NULL pointer check
as it is save to call kfree(NULL).
-Robert
> + if (ret)
> return ret;
> - }
>
> for_each_possible_cpu(cpu) {
> perf_events[cpu] = kcalloc(perf_num_counters,
> @@ -401,8 +401,9 @@ void oprofile_arch_exit(void)
> int cpu, id;
> struct perf_event *event;
>
> + exit_driverfs();
> +
> if (*perf_events) {
> - exit_driverfs();
> for_each_possible_cpu(cpu) {
> for (id = 0; id < perf_num_counters; ++id) {
> event = perf_events[cpu][id];
> --
> 1.7.1
>
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
WARNING: multiple messages have this Message-ID (diff)
From: Robert Richter <robert.richter@amd.com>
To: Matt Fleming <matt@console-pimps.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
Paul Mundt <lethal@linux-sh.org>,
Russell King <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>
Subject: Re: [PATCH 1/4] oprofile: Handle initialisation failure more
Date: Fri, 27 Aug 2010 12:43:44 +0000 [thread overview]
Message-ID: <20100827124344.GJ22783@erda.amd.com> (raw)
In-Reply-To: <442a16796990290ca3ebaaa3d0ab317e7b0a30a5.1282848651.git.matt@console-pimps.org>
On 26.08.10 15:09:16, Matt Fleming wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> The current implementation is not entirely safe in the case that
> oprofile_arch_init() fails. We need to make sure that we always call
> exit_driverfs() if we've called init_driverfs(). Also, avoid a potential
> double free when freeing 'counter_config', e.g. don't free
> 'counter_config' in both oprofile_arch_init() and oprofile_arch_exit().
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/oprofile/common.c | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> index 0691176..482779c 100644
> --- a/arch/arm/oprofile/common.c
> +++ b/arch/arm/oprofile/common.c
> @@ -275,10 +275,12 @@ out:
> return ret;
> }
>
> -static void exit_driverfs(void)
> +static void exit_driverfs(void)
> {
> - platform_device_unregister(oprofile_pdev);
> - platform_driver_unregister(&oprofile_driver);
> + if (!IS_ERR_OR_NULL(oprofile_pdev)) {
> + platform_device_unregister(oprofile_pdev);
> + platform_driver_unregister(&oprofile_driver);
> + }
The root cause that makes this check necessary is that
oprofile_arch_exit() is called though oprofile_arch_init() failed. We
should better fix this instead. I have to admit we will then have to
check all architectural implementations.
> }
> #else
> static int __init init_driverfs(void) { return 0; }
> @@ -363,10 +365,8 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> }
>
> ret = init_driverfs();
> - if (ret) {
> - kfree(counter_config);
We should not return from oprofile_arch_init() with allocated
resources if the function fails. To fix duplicate kfrees, we should
free it here and then set counter_config to NULL. It should also be
freed if for_each_possible_cpu() or op_name_from_perf_id() fails.
Also, the pointer should be NULLed after freeing in
oprofile_arch_exit(). There, we also don't need the NULL pointer check
as it is save to call kfree(NULL).
-Robert
> + if (ret)
> return ret;
> - }
>
> for_each_possible_cpu(cpu) {
> perf_events[cpu] = kcalloc(perf_num_counters,
> @@ -401,8 +401,9 @@ void oprofile_arch_exit(void)
> int cpu, id;
> struct perf_event *event;
>
> + exit_driverfs();
> +
> if (*perf_events) {
> - exit_driverfs();
> for_each_possible_cpu(cpu) {
> for (id = 0; id < perf_num_counters; ++id) {
> event = perf_events[cpu][id];
> --
> 1.7.1
>
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
WARNING: multiple messages have this Message-ID (diff)
From: robert.richter@amd.com (Robert Richter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4] oprofile: Handle initialisation failure more gracefully
Date: Fri, 27 Aug 2010 14:43:44 +0200 [thread overview]
Message-ID: <20100827124344.GJ22783@erda.amd.com> (raw)
In-Reply-To: <442a16796990290ca3ebaaa3d0ab317e7b0a30a5.1282848651.git.matt@console-pimps.org>
On 26.08.10 15:09:16, Matt Fleming wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> The current implementation is not entirely safe in the case that
> oprofile_arch_init() fails. We need to make sure that we always call
> exit_driverfs() if we've called init_driverfs(). Also, avoid a potential
> double free when freeing 'counter_config', e.g. don't free
> 'counter_config' in both oprofile_arch_init() and oprofile_arch_exit().
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/oprofile/common.c | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> index 0691176..482779c 100644
> --- a/arch/arm/oprofile/common.c
> +++ b/arch/arm/oprofile/common.c
> @@ -275,10 +275,12 @@ out:
> return ret;
> }
>
> -static void exit_driverfs(void)
> +static void exit_driverfs(void)
> {
> - platform_device_unregister(oprofile_pdev);
> - platform_driver_unregister(&oprofile_driver);
> + if (!IS_ERR_OR_NULL(oprofile_pdev)) {
> + platform_device_unregister(oprofile_pdev);
> + platform_driver_unregister(&oprofile_driver);
> + }
The root cause that makes this check necessary is that
oprofile_arch_exit() is called though oprofile_arch_init() failed. We
should better fix this instead. I have to admit we will then have to
check all architectural implementations.
> }
> #else
> static int __init init_driverfs(void) { return 0; }
> @@ -363,10 +365,8 @@ int __init oprofile_arch_init(struct oprofile_operations *ops)
> }
>
> ret = init_driverfs();
> - if (ret) {
> - kfree(counter_config);
We should not return from oprofile_arch_init() with allocated
resources if the function fails. To fix duplicate kfrees, we should
free it here and then set counter_config to NULL. It should also be
freed if for_each_possible_cpu() or op_name_from_perf_id() fails.
Also, the pointer should be NULLed after freeing in
oprofile_arch_exit(). There, we also don't need the NULL pointer check
as it is save to call kfree(NULL).
-Robert
> + if (ret)
> return ret;
> - }
>
> for_each_possible_cpu(cpu) {
> perf_events[cpu] = kcalloc(perf_num_counters,
> @@ -401,8 +401,9 @@ void oprofile_arch_exit(void)
> int cpu, id;
> struct perf_event *event;
>
> + exit_driverfs();
> +
> if (*perf_events) {
> - exit_driverfs();
> for_each_possible_cpu(cpu) {
> for (id = 0; id < perf_num_counters; ++id) {
> event = perf_events[cpu][id];
> --
> 1.7.1
>
>
--
Advanced Micro Devices, Inc.
Operating System Research Center
next prev parent reply other threads:[~2010-08-27 12:56 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 19:09 [PATCH V2 0/4] Generalise ARM perf-events backend for oprofile Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-27 12:43 ` Robert Richter [this message]
2010-08-27 12:43 ` Robert Richter
2010-08-27 12:43 ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-27 15:15 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Will Deacon
2010-08-27 15:15 ` Will Deacon
2010-08-27 15:15 ` [PATCH 1/4] oprofile: Handle initialisation failure more Will Deacon
2010-08-27 16:38 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Robert Richter
2010-08-27 16:38 ` Robert Richter
2010-08-27 16:38 ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-27 18:06 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Will Deacon
2010-08-27 18:06 ` Will Deacon
2010-08-27 18:06 ` [PATCH 1/4] oprofile: Handle initialisation failure more Will Deacon
2010-08-27 19:47 ` [PATCH 1/4] oprofile: Handle initialisation failure more gracefully Robert Richter
2010-08-27 19:47 ` Robert Richter
2010-08-27 19:47 ` [PATCH 1/4] oprofile: Handle initialisation failure more Robert Richter
2010-08-26 19:09 ` [PATCH 2/4] sh: Accessor functions for the sh_pmu state Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-27 13:43 ` Robert Richter
2010-08-27 13:43 ` Robert Richter
2010-08-27 13:43 ` Robert Richter
2010-08-27 19:17 ` Matt Fleming
2010-08-27 19:17 ` Matt Fleming
2010-08-27 19:17 ` Matt Fleming
2010-08-30 12:41 ` Robert Richter
2010-08-30 12:41 ` Robert Richter
2010-08-30 12:41 ` Robert Richter
2010-08-26 19:09 ` [PATCH V2 3/4] oprofile: Abstract the perf-events backend Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-27 10:41 ` Will Deacon
2010-08-27 10:41 ` Will Deacon
2010-08-27 10:41 ` Will Deacon
2010-08-27 12:44 ` Matt Fleming
2010-08-27 12:44 ` Matt Fleming
2010-08-27 12:44 ` Matt Fleming
2010-08-27 12:59 ` Robert Richter
2010-08-27 12:59 ` Robert Richter
2010-08-27 12:59 ` Robert Richter
2010-08-27 14:31 ` Robert Richter
2010-08-27 14:31 ` Robert Richter
2010-08-27 14:31 ` Robert Richter
2010-08-26 19:09 ` [PATCH V2 4/4] sh: Use the perf-events backend for oprofile Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-26 19:09 ` Matt Fleming
2010-08-27 14:59 ` Robert Richter
2010-08-27 14:59 ` Robert Richter
2010-08-27 14:59 ` Robert Richter
2010-08-27 20:19 ` Matt Fleming
2010-08-27 20:19 ` Matt Fleming
2010-08-27 20:19 ` Matt Fleming
2010-08-31 11:28 ` Robert Richter
2010-08-31 11:28 ` Robert Richter
2010-08-31 11:28 ` Robert Richter
2010-08-31 12:23 ` Matt Fleming
2010-08-31 12:23 ` Matt Fleming
2010-08-31 12:23 ` Matt Fleming
2010-08-31 13:26 ` Robert Richter
2010-08-31 13:26 ` Robert Richter
2010-08-31 13:26 ` Robert Richter
2010-08-31 11:05 ` [PATCH V2 0/4] Generalise ARM " Robert Richter
2010-08-31 11:05 ` Robert Richter
2010-08-31 11:05 ` Robert Richter
2010-08-31 11:25 ` Matt Fleming
2010-08-31 11:25 ` Matt Fleming
2010-08-31 11:25 ` Matt Fleming
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=20100827124344.GJ22783@erda.amd.com \
--to=robert.richter@amd.com \
--cc=acme@redhat.com \
--cc=fweisbec@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=matt@console-pimps.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.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.