public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Richter <tmricht@linux.ibm.com>
To: linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-perf-users@vger.kernel.org, acme@kernel.org,
	namhyung@kernel.org, irogers@google.com, acme@redhat.com
Cc: agordeev@linux.ibm.com, gor@linux.ibm.com,
	sumanthk@linux.ibm.com, hca@linux.ibm.com,
	Thomas Richter <tmricht@linux.ibm.com>
Subject: [PATCH 1/2] perf/bench: Fix perf bench internals pmu-scan core dump
Date: Tue, 18 Mar 2025 10:51:31 +0100	[thread overview]
Message-ID: <20250318095132.1502654-2-tmricht@linux.ibm.com> (raw)
In-Reply-To: <20250318095132.1502654-1-tmricht@linux.ibm.com>

On s390 z/VM systems the command 'perf bench internals pmu-scan'
dumps core, as can be seen:

 # ./perf bench internals pmu-scan
 # Running 'internals/pmu-scan' benchmark:
 Computing performance of sysfs PMU event scan for 100 times
 double free or corruption (out)
 Aborted (core dumped)
 # gdb ./perf core.xxxx
 ....
 #9  0x00000000012fb57a in perf_pmu__delete (pmu=0x160e370 <tool>)
     at util/pmu.c:2318
 #10 0x00000000012fbfca in perf_pmus__destroy () at util/pmus.c:103
 #11 0x0000000001186f72 in save_result () at bench/pmu-scan.c:71
 #12 0x00000000011873c2 in run_pmu_scan () at bench/pmu-scan.c:140
 #13 0x00000000011876a8 in bench_pmu_scan (argc=0, argv=0x3fff3a77338)
     at bench/pmu-scan.c:183
 #14 0x0000000001174556 in run_bench (coll_name=0x14709ba "internals",
     bench_name=0x1470700 "pmu-scan", fn=0x1187620 <bench_pmu_scan>,
     argc=1, argv=0x3fff3a77338) at builtin-bench.c:229
 #15 0x0000000001174a1e in cmd_bench (argc=2, argv=0x3fff3a77330)
     at builtin-bench.c:330
 ...

The root cause is in PMU buildup. The PMUs are constructed via

  run_bench()
  +--> bench_pmu_scan()
       +--> run_pmu_scan()
	    +--> save_result()
	         +--> perf_pmus__scan()
	              +--> pmu_read_sysfs()
	                   +--> perf_pmus__tool_pmu()

perf_pmus__tool_pmu() returns a pointer to a static defined variable:

  static struct perf_pmu tool = {
                .name = "tool",
                .type = PERF_PMU_TYPE_TOOL,
                .aliases = LIST_HEAD_INIT(tool.aliases),
                .caps = LIST_HEAD_INIT(tool.caps),
                .format = LIST_HEAD_INIT(tool.format),
  };

and that PMU is added to the list of other_cpus in file
./util/pmus.c, function pmu_read_sysfs().

Later on after the list of PMUs is constructed,
that list is removed again via:

   save_result()
   +--> perf_pmus__destroy()
	+--> perf_pmu__delete()

This works fine until the PMU named "tool" is deleted.
Its name is a constant pointer possibly located in read-only data
section and can not be freed using zfree().

Remedy this and check for dynamic memory allocation for the PMU.

Background: s390 z/VM system do not support PMUs for sampling and
counting. In this case dummy events are created by the perf tool
and the PMUs "tool" and "fake" are created and freed.

Fixes: efe98a7a3977 ("perf pmu: Use zfree() to reduce chances of use after free")
Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Ian Rogers <irogers@google.com>
---
 tools/perf/util/pmu.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 6206c8fe2bf9..59cec4d2909e 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -2315,10 +2315,13 @@ void perf_pmu__delete(struct perf_pmu *pmu)
 
 	perf_cpu_map__put(pmu->cpus);
 
-	zfree(&pmu->name);
-	zfree(&pmu->alias_name);
-	zfree(&pmu->id);
-	free(pmu);
+	/* Static variables can not be free'ed */
+	if (pmu->type != PERF_PMU_TYPE_TOOL && pmu->type != PERF_PMU_TYPE_FAKE) {
+		zfree(&pmu->alias_name);
+		zfree(&pmu->id);
+		zfree(&pmu->name);
+		free(pmu);
+	}
 }
 
 const char *perf_pmu__name_from_config(struct perf_pmu *pmu, u64 config)
-- 
2.48.1


  reply	other threads:[~2025-03-18  9:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-18  9:51 [PATCH 0/2] perf bench: Fix core dumps on s390 z/VM Thomas Richter
2025-03-18  9:51 ` Thomas Richter [this message]
2025-03-18 16:28   ` [PATCH 1/2] perf/bench: Fix perf bench internals pmu-scan core dump Ian Rogers
2025-03-18  9:51 ` [PATCH 2/2] perf/bench: Double free of dynamic allocated memory Thomas Richter
2025-03-18 16:37   ` Ian Rogers

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=20250318095132.1502654-2-tmricht@linux.ibm.com \
    --to=tmricht@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=agordeev@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=sumanthk@linux.ibm.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