* Re: [PATCH resent] perf/x86/amd/uncore: Fix exception handling in amd_uncore_cpu_up_prepare()
[not found] ` <3a35fb28-5937-72f8-b2e8-b1d9899b5e43@web.de>
@ 2023-03-27 9:11 ` Adrian Hunter
2023-03-27 14:58 ` Peter Zijlstra
0 siblings, 1 reply; 3+ messages in thread
From: Adrian Hunter @ 2023-03-27 9:11 UTC (permalink / raw)
To: Markus Elfring, kernel-janitors, linux-perf-users,
Arnaldo Carvalho de Melo, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Ian Rogers, Ingo Molnar, Jiri Olsa, Mark Rutland,
Namhyung Kim, Peter Zijlstra, Sandipan Das, Thomas Gleixner,
Zhouyi Zhou, x86
Cc: cocci, LKML
On 25/03/23 16:15, Markus Elfring wrote:
> Date: Fri, 17 Mar 2023 13:13:14 +0100
>
> The label “fail” was used to jump to another pointer check despite of
> the detail in the implementation of the function “amd_uncore_cpu_up_prepare”
> that it was determined already that the corresponding variable contained
> a null pointer (because of a failed function call in two cases).
>
> 1. Thus return directly after a call of the function “amd_uncore_alloc”
> failed in the first if branch.
>
> 2. Use more appropriate labels instead.
>
> 3. Reorder jump targets at the end.
>
> 4. Delete a redundant check and kfree() call.
>
> 5. Omit an explicit initialisation for the local variable “uncore_llc”.
>
>
> This issue was detected by using the Coccinelle software.
>
> Fixes: 39621c5808f5dda75d03dc4b2d4d2b13a5a1c34b ("perf/x86/amd/uncore: Use dynamic events array")
> Fixes: 503d3291a937b726757c1f7c45fa02389d2f4324 ("perf/x86/amd: Try to fix some mem allocation failure handling")
Commit should be only the first 12 characters of the hash.
Refer: https://docs.kernel.org/process/submitting-patches.html
But this is not a fix. Redundant calls to kfree do not break
anything.
Also avoid using the term "exception" since, in x86, exceptions are
hardware events. Better to just call it "error handling".
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> arch/x86/events/amd/uncore.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
> index 83f15fe411b3..0a9b5cb97bb4 100644
> --- a/arch/x86/events/amd/uncore.c
> +++ b/arch/x86/events/amd/uncore.c
> @@ -440,13 +440,13 @@ amd_uncore_events_alloc(unsigned int num, unsigned int cpu)
>
> static int amd_uncore_cpu_up_prepare(unsigned int cpu)
> {
> - struct amd_uncore *uncore_nb = NULL, *uncore_llc = NULL;
> + struct amd_uncore *uncore_nb = NULL, *uncore_llc;
>
> if (amd_uncore_nb) {
> *per_cpu_ptr(amd_uncore_nb, cpu) = NULL;
> uncore_nb = amd_uncore_alloc(cpu);
> if (!uncore_nb)
> - goto fail;
> + return -ENOMEM;
> uncore_nb->cpu = cpu;
> uncore_nb->num_counters = num_counters_nb;
> uncore_nb->rdpmc_base = RDPMC_BASE_NB;
> @@ -455,7 +455,7 @@ static int amd_uncore_cpu_up_prepare(unsigned int cpu)
> uncore_nb->pmu = &amd_nb_pmu;
> uncore_nb->events = amd_uncore_events_alloc(num_counters_nb, cpu);
> if (!uncore_nb->events)
> - goto fail;
> + goto free_nb;
> uncore_nb->id = -1;
> *per_cpu_ptr(amd_uncore_nb, cpu) = uncore_nb;
> }
> @@ -464,7 +464,7 @@ static int amd_uncore_cpu_up_prepare(unsigned int cpu)
> *per_cpu_ptr(amd_uncore_llc, cpu) = NULL;
> uncore_llc = amd_uncore_alloc(cpu);
> if (!uncore_llc)
> - goto fail;
> + goto check_uncore_nb;
> uncore_llc->cpu = cpu;
> uncore_llc->num_counters = num_counters_llc;
> uncore_llc->rdpmc_base = RDPMC_BASE_LLC;
> @@ -473,24 +473,22 @@ static int amd_uncore_cpu_up_prepare(unsigned int cpu)
> uncore_llc->pmu = &amd_llc_pmu;
> uncore_llc->events = amd_uncore_events_alloc(num_counters_llc, cpu);
> if (!uncore_llc->events)
> - goto fail;
> + goto free_llc;
> uncore_llc->id = -1;
> *per_cpu_ptr(amd_uncore_llc, cpu) = uncore_llc;
> }
>
> return 0;
>
> -fail:
> +free_llc:
> + kfree(uncore_llc);
> +check_uncore_nb:
> if (uncore_nb) {
> kfree(uncore_nb->events);
> +free_nb:
> kfree(uncore_nb);
> }
>
> - if (uncore_llc) {
> - kfree(uncore_llc->events);
> - kfree(uncore_llc);
> - }
> -
> return -ENOMEM;
> }
>
> --
> 2.40.0
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH resent] perf/x86/amd/uncore: Fix exception handling in amd_uncore_cpu_up_prepare()
2023-03-27 9:11 ` [PATCH resent] perf/x86/amd/uncore: Fix exception handling in amd_uncore_cpu_up_prepare() Adrian Hunter
@ 2023-03-27 14:58 ` Peter Zijlstra
0 siblings, 0 replies; 3+ messages in thread
From: Peter Zijlstra @ 2023-03-27 14:58 UTC (permalink / raw)
To: Adrian Hunter
Cc: Markus Elfring, kernel-janitors, linux-perf-users,
Arnaldo Carvalho de Melo, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Ian Rogers, Ingo Molnar, Jiri Olsa, Mark Rutland,
Namhyung Kim, Sandipan Das, Thomas Gleixner, Zhouyi Zhou, x86,
cocci, LKML
On Mon, Mar 27, 2023 at 12:11:54PM +0300, Adrian Hunter wrote:
> On 25/03/23 16:15, Markus Elfring wrote:
> > Date: Fri, 17 Mar 2023 13:13:14 +0100
> >
> > The label “fail” was used to jump to another pointer check despite of
> > the detail in the implementation of the function “amd_uncore_cpu_up_prepare”
> > that it was determined already that the corresponding variable contained
> > a null pointer (because of a failed function call in two cases).
> >
> > 1. Thus return directly after a call of the function “amd_uncore_alloc”
> > failed in the first if branch.
> >
> > 2. Use more appropriate labels instead.
> >
> > 3. Reorder jump targets at the end.
> >
> > 4. Delete a redundant check and kfree() call.
> >
> > 5. Omit an explicit initialisation for the local variable “uncore_llc”.
> >
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Fixes: 39621c5808f5dda75d03dc4b2d4d2b13a5a1c34b ("perf/x86/amd/uncore: Use dynamic events array")
> > Fixes: 503d3291a937b726757c1f7c45fa02389d2f4324 ("perf/x86/amd: Try to fix some mem allocation failure handling")
>
> Commit should be only the first 12 characters of the hash.
> Refer: https://docs.kernel.org/process/submitting-patches.html
>
> But this is not a fix. Redundant calls to kfree do not break
> anything.
>
> Also avoid using the term "exception" since, in x86, exceptions are
> hardware events. Better to just call it "error handling".
Don't feed the trolls; Markus is a bot or other weird construct that's
been banned from lkml.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH RESEND] perf cputopo: Improve exception handling in build_cpu_topology()
[not found] ` <b1c70348-6459-474e-6a0f-d956423368d5@web.de>
@ 2025-03-04 9:50 ` Markus Elfring
0 siblings, 0 replies; 3+ messages in thread
From: Markus Elfring @ 2025-03-04 9:50 UTC (permalink / raw)
To: kernel-janitors, linux-perf-users, Adrian Hunter,
Alexander Shishkin, Arnaldo Carvalho de Melo, Ian Rogers,
Ingo Molnar, James Clark, Jiri Olsa, Kan Liang, Leo Yan,
Mark Rutland, Namhyung Kim, Peter Zijlstra, Suzuki Poulouse
Cc: cocci, LKML
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 23 Mar 2023 22:00:07 +0100
The label “done” was used to jump to another pointer check despite of
the detail in the implementation of the function “build_cpu_topology”
that it was determined already that a corresponding variable contained
a null pointer because of a failed call of the function “fopen”.
1. Thus use more appropriate labels instead.
2. Reorder jump targets at the end.
3. Delete a redundant check.
This issue was detected by using the Coccinelle software.
Fixes: 5135d5efcbb4 ("perf tools: Add cpu_topology object")
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
tools/perf/util/cputopo.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/cputopo.c b/tools/perf/util/cputopo.c
index e08797c3cdbc..fd185951ee2c 100644
--- a/tools/perf/util/cputopo.c
+++ b/tools/perf/util/cputopo.c
@@ -112,10 +112,10 @@ static int build_cpu_topology(struct cpu_topology *tp, int cpu)
}
fp = fopen(filename, "r");
if (!fp)
- goto done;
+ goto exit;
if (getline(&buf, &len, fp) <= 0)
- goto done;
+ goto close_file;
p = strchr(buf, '\n');
if (p)
@@ -131,10 +131,10 @@ static int build_cpu_topology(struct cpu_topology *tp, int cpu)
buf = NULL;
}
ret = 0;
-done:
- if (fp)
- fclose(fp);
free(buf);
+close_file:
+ fclose(fp);
+exit:
return ret;
}
--
2.40.0
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-03-04 9:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <f9303bdc-b1a7-be5e-56c6-dfa8232b8b55@web.de>
[not found] ` <ab860edf-79ca-2035-c5a3-d25be6fd9dac@web.de>
[not found] ` <3a35fb28-5937-72f8-b2e8-b1d9899b5e43@web.de>
2023-03-27 9:11 ` [PATCH resent] perf/x86/amd/uncore: Fix exception handling in amd_uncore_cpu_up_prepare() Adrian Hunter
2023-03-27 14:58 ` Peter Zijlstra
[not found] ` <b1c70348-6459-474e-6a0f-d956423368d5@web.de>
2025-03-04 9:50 ` [PATCH RESEND] perf cputopo: Improve exception handling in build_cpu_topology() Markus Elfring
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).