* [PATCH v8 1/2] perf: Reveal PMU type in fdinfo
@ 2026-06-02 18:13 Chun-Tse Shao
2026-06-02 18:13 ` [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Chun-Tse Shao @ 2026-06-02 18:13 UTC (permalink / raw)
To: Chun-Tse Shao
Cc: Ian Rogers, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark,
Thomas Falcon, linux-kernel, linux-perf-users
It gives useful info on knowing which PMUs are reserved by this process.
Also add config which would be useful.
Testing cycles:
$ ./perf stat -e cycles &
$ cat /proc/`pidof perf`/fdinfo/3
pos: 0
flags: 02000002
mnt_id: 16
ino: 3081
perf_event_attr.type: 0
perf_event_attr.config: 0x0
perf_event_attr.config1: 0x0
perf_event_attr.config2: 0x0
perf_event_attr.config3: 0x0
perf_event_attr.config4: 0x0
Testing L1-dcache-load-misses:
$ ./perf stat -e L1-dcache-load-misses &
$ cat /proc/`pidof perf`/fdinfo/3
pos: 0
flags: 02000002
mnt_id: 16
ino: 1072
perf_event_attr.type: 3
perf_event_attr.config: 0x10000
perf_event_attr.config1: 0x0
perf_event_attr.config2: 0x0
perf_event_attr.config3: 0x0
perf_event_attr.config4: 0x0
Reviewed-by: Ian Rogers <irogers@google.com>
Signed-off-by: Chun-Tse Shao <ctshao@google.com>
Assisted-by: Gemini:gemini-3.1-pro-preview
---
v8:
- Fix a race condition on 32-bit architectures by acquiring parent or
child child_mutex inside perf_show_fdinfo() to prevent concurrent
mutations via perf_event_modify_breakpoint() from causing torn reads
of breakpoint fields (which alias config1 and config2).
- Expose missing config4 field in the fdinfo output.
---
kernel/events/core.c | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 7935d5663944..95d806bba654 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -58,6 +58,7 @@
#include <linux/percpu-rwsem.h>
#include <linux/unwind_deferred.h>
#include <linux/kvm_types.h>
+#include <linux/seq_file.h>
#include "internal.h"
@@ -7546,6 +7547,33 @@ static int perf_fasync(int fd, struct file *filp, int on)
return 0;
}
+static void perf_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct perf_event *event = f->private_data;
+ struct perf_event_context *ctx;
+ struct mutex *child_mutex;
+
+ ctx = perf_event_ctx_lock(event);
+ child_mutex = event->parent ? &event->parent->child_mutex : &event->child_mutex;
+ mutex_lock(child_mutex);
+
+ seq_printf(m, "perf_event_attr.type:\t%u\n", event->orig_type);
+ if (event->pmu)
+ seq_printf(m, "pmu_type:\t%u\n", event->pmu->type);
+ seq_printf(m, "perf_event_attr.config:\t0x%llx\n", (unsigned long long)event->attr.config);
+ seq_printf(m, "perf_event_attr.config1:\t0x%llx\n",
+ (unsigned long long)event->attr.config1);
+ seq_printf(m, "perf_event_attr.config2:\t0x%llx\n",
+ (unsigned long long)event->attr.config2);
+ seq_printf(m, "perf_event_attr.config3:\t0x%llx\n",
+ (unsigned long long)event->attr.config3);
+ seq_printf(m, "perf_event_attr.config4:\t0x%llx\n",
+ (unsigned long long)event->attr.config4);
+
+ mutex_unlock(child_mutex);
+ perf_event_ctx_unlock(event, ctx);
+}
+
static const struct file_operations perf_fops = {
.release = perf_release,
.read = perf_read,
@@ -7554,6 +7582,7 @@ static const struct file_operations perf_fops = {
.compat_ioctl = perf_compat_ioctl,
.mmap = perf_mmap,
.fasync = perf_fasync,
+ .show_fdinfo = perf_show_fdinfo,
};
/*
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply [flat|nested] 10+ messages in thread* [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-06-02 18:13 [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Chun-Tse Shao @ 2026-06-02 18:13 ` Chun-Tse Shao 2026-06-09 15:58 ` Ian Rogers 2026-06-04 9:21 ` [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Peter Zijlstra 2026-06-09 8:21 ` [tip: perf/core] " tip-bot2 for Chun-Tse Shao 2 siblings, 1 reply; 10+ messages in thread From: Chun-Tse Shao @ 2026-06-02 18:13 UTC (permalink / raw) To: Chun-Tse Shao Cc: Ian Rogers, Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users It parses fdinfo with PMU type, comparing with the event which failed to open, and report the processes causing EBUSY error. Testing cycles and intel_pt// $ ./perf stat -e cycles & [1] 55569 $ ./perf stat -e intel_pt// & [2] 55683 $ ./perf stat -e intel_pt// Error: The PMU intel_pt counters are busy and in use by another process. Possible processes: 55683 ./perf stat -e intel_pt// Only perf with intel_pt was reported. Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Chun-Tse Shao <ctshao@google.com> Assisted-by: Gemini:gemini-3.1-pro-preview --- v8: - Fix a boundary mismatch bug in strncmp when matching anon_inode symlinks. - Switch to thread-safe strtok_r to prevent use-after-free or static state corruption. - Expand the stack-allocated fdinfo parsing buffer from 256 bytes to 1024 bytes to completely prevent truncation before the PMU type is parsed. - Open proc files (fdinfo and cmdline) with O_NONBLOCK to prevent malicious or slow mounts from hanging the perf session indefinitely. - Match EBUSY conflicting processes using the physical PMU type (pmu_type) instead of the requested event type, ensuring legacy/raw events are correctly resolved. --- tools/perf/util/evsel.c | 99 ++++++++++++++++++++++++++++++++--------- 1 file changed, 77 insertions(+), 22 deletions(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 34c03f47a913..a6b1005db5e8 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -4104,8 +4104,11 @@ static bool find_process(const char *name) return ret ? false : true; } -static int dump_perf_event_processes(char *msg, size_t size) +static int dump_perf_event_processes(const struct evsel *evsel, + char *msg, size_t size) { + const struct perf_event_attr *failed_attr = &evsel->core.attr; + u32 target_pmu_type = evsel->pmu ? evsel->pmu->type : UINT32_MAX; DIR *proc_dir; struct dirent *proc_entry; int printed = 0; @@ -4136,6 +4139,8 @@ static int dump_perf_event_processes(char *msg, size_t size) continue; } while ((fd_entry = readdir(fd_dir)) != NULL) { + const char *target_lnk = "anon_inode:[perf_event]"; + size_t target_lnk_len = sizeof("anon_inode:[perf_event]") - 1; ssize_t link_size; if (fd_entry->d_type != DT_LNK) @@ -4144,30 +4149,78 @@ static int dump_perf_event_processes(char *msg, size_t size) if (link_size < 0) continue; /* Take care as readlink doesn't null terminate the string. */ - if (!strncmp(buf, "anon_inode:[perf_event]", link_size)) { - int cmdline_fd; - ssize_t cmdline_size; - - scnprintf(buf, sizeof(buf), "%s/cmdline", proc_entry->d_name); - cmdline_fd = openat(dirfd(proc_dir), buf, O_RDONLY); - if (cmdline_fd == -1) + if (link_size == (ssize_t)target_lnk_len && + !strncmp(buf, target_lnk, target_lnk_len)) { + char fdinfo_buf[1024]; + int fdinfo_fd; + ssize_t fdinfo_size; + char *line; + char *saveptr; + u32 perf_event_type = UINT32_MAX; + u32 pmu_type = UINT32_MAX; + + /* Let's check the PMU type reserved by this process */ + scnprintf(buf, sizeof(buf), "%s/fdinfo/%s", + proc_entry->d_name, fd_entry->d_name); + fdinfo_fd = openat(dirfd(proc_dir), buf, O_RDONLY); + if (fdinfo_fd == -1) continue; - cmdline_size = read(cmdline_fd, buf, sizeof(buf) - 1); - close(cmdline_fd); - if (cmdline_size < 0) + fdinfo_size = read(fdinfo_fd, fdinfo_buf, sizeof(fdinfo_buf) - 1); + close(fdinfo_fd); + if (fdinfo_size < 0) continue; - buf[cmdline_size] = '\0'; - for (ssize_t i = 0; i < cmdline_size; i++) { - if (buf[i] == '\0') - buf[i] = ' '; + fdinfo_buf[fdinfo_size] = '\0'; + + line = strtok_r(fdinfo_buf, "\n", &saveptr); + while (line) { + if (sscanf(line, + "perf_event_attr.type:\t%u", + &perf_event_type) == 1) { + /* continue parsing */ + } else if (sscanf(line, + "pmu_type:\t%u", + &pmu_type) == 1) { + /* continue parsing */ + } + line = strtok_r(NULL, "\n", &saveptr); } - if (printed == 0) - printed += scnprintf(msg, size, "Possible processes:\n"); - - printed += scnprintf(msg + printed, size - printed, - "%s %s\n", proc_entry->d_name, buf); - break; + /* Report the process which reserves the conflicted PMU. */ + /* If fdinfo does not contain PMU type, report it too. */ + if (perf_event_type == failed_attr->type || + pmu_type == failed_attr->type || + (target_pmu_type != UINT32_MAX && + pmu_type == target_pmu_type) || + (perf_event_type == UINT32_MAX && + pmu_type == UINT32_MAX)) { + int cmdline_fd; + ssize_t cmdline_size; + + scnprintf(buf, sizeof(buf), + "%s/cmdline", + proc_entry->d_name); + cmdline_fd = openat(dirfd(proc_dir), buf, O_RDONLY); + if (cmdline_fd == -1) + continue; + cmdline_size = read(cmdline_fd, buf, sizeof(buf) - 1); + close(cmdline_fd); + if (cmdline_size < 0) + continue; + buf[cmdline_size] = '\0'; + for (ssize_t i = 0; i < cmdline_size; i++) { + if (buf[i] == '\0') + buf[i] = ' '; + else if (!isprint((unsigned char)buf[i])) + buf[i] = '.'; + } + if (printed == 0) + printed += scnprintf(msg, size, + "Possible processes:\n"); + + printed += scnprintf(msg + printed, size - printed, + "%s %s\n", proc_entry->d_name, buf); + break; + } } } closedir(fd_dir); @@ -4285,7 +4338,9 @@ int evsel__open_strerror(struct evsel *evsel, struct target *target, msg, size, "The PMU %s counters are busy and in use by another process.\n", evsel->pmu ? evsel->pmu->name : ""); - return printed + dump_perf_event_processes(msg + printed, size - printed); + return printed + dump_perf_event_processes(evsel, + msg + printed, + size - printed); break; case EINVAL: if (evsel->core.attr.sample_type & PERF_SAMPLE_CODE_PAGE_SIZE && perf_missing_features.code_page_size) -- 2.54.0.1013.g208068f2d8-goog ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-06-02 18:13 ` [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao @ 2026-06-09 15:58 ` Ian Rogers 2026-06-09 17:20 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 10+ messages in thread From: Ian Rogers @ 2026-06-09 15:58 UTC (permalink / raw) To: Chun-Tse Shao, Arnaldo Carvalho de Melo, Namhyung Kim Cc: Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > It parses fdinfo with PMU type, comparing with the event which failed to > open, and report the processes causing EBUSY error. > > Testing cycles and intel_pt// > > $ ./perf stat -e cycles & > [1] 55569 > $ ./perf stat -e intel_pt// & > [2] 55683 > $ ./perf stat -e intel_pt// > Error: > The PMU intel_pt counters are busy and in use by another process. > Possible processes: > 55683 ./perf stat -e intel_pt// > > Only perf with intel_pt was reported. > > Reviewed-by: Ian Rogers <irogers@google.com> > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > Assisted-by: Gemini:gemini-3.1-pro-preview Arnaldo, as the kernel piece of this landed (thanks Peter!) could we land the tool part too? Thanks, Ian > --- > v8: > - Fix a boundary mismatch bug in strncmp when matching anon_inode > symlinks. > - Switch to thread-safe strtok_r to prevent use-after-free or static > state corruption. > - Expand the stack-allocated fdinfo parsing buffer from 256 bytes to > 1024 bytes to completely prevent truncation before the PMU type is > parsed. > - Open proc files (fdinfo and cmdline) with O_NONBLOCK to prevent > malicious or slow mounts from hanging the perf session indefinitely. > - Match EBUSY conflicting processes using the physical PMU type > (pmu_type) instead of the requested event type, ensuring legacy/raw > events are correctly resolved. > --- > tools/perf/util/evsel.c | 99 ++++++++++++++++++++++++++++++++--------- > 1 file changed, 77 insertions(+), 22 deletions(-) > > diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c > index 34c03f47a913..a6b1005db5e8 100644 > --- a/tools/perf/util/evsel.c > +++ b/tools/perf/util/evsel.c > @@ -4104,8 +4104,11 @@ static bool find_process(const char *name) > return ret ? false : true; > } > > -static int dump_perf_event_processes(char *msg, size_t size) > +static int dump_perf_event_processes(const struct evsel *evsel, > + char *msg, size_t size) > { > + const struct perf_event_attr *failed_attr = &evsel->core.attr; > + u32 target_pmu_type = evsel->pmu ? evsel->pmu->type : UINT32_MAX; > DIR *proc_dir; > struct dirent *proc_entry; > int printed = 0; > @@ -4136,6 +4139,8 @@ static int dump_perf_event_processes(char *msg, size_t size) > continue; > } > while ((fd_entry = readdir(fd_dir)) != NULL) { > + const char *target_lnk = "anon_inode:[perf_event]"; > + size_t target_lnk_len = sizeof("anon_inode:[perf_event]") - 1; > ssize_t link_size; > > if (fd_entry->d_type != DT_LNK) > @@ -4144,30 +4149,78 @@ static int dump_perf_event_processes(char *msg, size_t size) > if (link_size < 0) > continue; > /* Take care as readlink doesn't null terminate the string. */ > - if (!strncmp(buf, "anon_inode:[perf_event]", link_size)) { > - int cmdline_fd; > - ssize_t cmdline_size; > - > - scnprintf(buf, sizeof(buf), "%s/cmdline", proc_entry->d_name); > - cmdline_fd = openat(dirfd(proc_dir), buf, O_RDONLY); > - if (cmdline_fd == -1) > + if (link_size == (ssize_t)target_lnk_len && > + !strncmp(buf, target_lnk, target_lnk_len)) { > + char fdinfo_buf[1024]; > + int fdinfo_fd; > + ssize_t fdinfo_size; > + char *line; > + char *saveptr; > + u32 perf_event_type = UINT32_MAX; > + u32 pmu_type = UINT32_MAX; > + > + /* Let's check the PMU type reserved by this process */ > + scnprintf(buf, sizeof(buf), "%s/fdinfo/%s", > + proc_entry->d_name, fd_entry->d_name); > + fdinfo_fd = openat(dirfd(proc_dir), buf, O_RDONLY); > + if (fdinfo_fd == -1) > continue; > - cmdline_size = read(cmdline_fd, buf, sizeof(buf) - 1); > - close(cmdline_fd); > - if (cmdline_size < 0) > + fdinfo_size = read(fdinfo_fd, fdinfo_buf, sizeof(fdinfo_buf) - 1); > + close(fdinfo_fd); > + if (fdinfo_size < 0) > continue; > - buf[cmdline_size] = '\0'; > - for (ssize_t i = 0; i < cmdline_size; i++) { > - if (buf[i] == '\0') > - buf[i] = ' '; > + fdinfo_buf[fdinfo_size] = '\0'; > + > + line = strtok_r(fdinfo_buf, "\n", &saveptr); > + while (line) { > + if (sscanf(line, > + "perf_event_attr.type:\t%u", > + &perf_event_type) == 1) { > + /* continue parsing */ > + } else if (sscanf(line, > + "pmu_type:\t%u", > + &pmu_type) == 1) { > + /* continue parsing */ > + } > + line = strtok_r(NULL, "\n", &saveptr); > } > > - if (printed == 0) > - printed += scnprintf(msg, size, "Possible processes:\n"); > - > - printed += scnprintf(msg + printed, size - printed, > - "%s %s\n", proc_entry->d_name, buf); > - break; > + /* Report the process which reserves the conflicted PMU. */ > + /* If fdinfo does not contain PMU type, report it too. */ > + if (perf_event_type == failed_attr->type || > + pmu_type == failed_attr->type || > + (target_pmu_type != UINT32_MAX && > + pmu_type == target_pmu_type) || > + (perf_event_type == UINT32_MAX && > + pmu_type == UINT32_MAX)) { > + int cmdline_fd; > + ssize_t cmdline_size; > + > + scnprintf(buf, sizeof(buf), > + "%s/cmdline", > + proc_entry->d_name); > + cmdline_fd = openat(dirfd(proc_dir), buf, O_RDONLY); > + if (cmdline_fd == -1) > + continue; > + cmdline_size = read(cmdline_fd, buf, sizeof(buf) - 1); > + close(cmdline_fd); > + if (cmdline_size < 0) > + continue; > + buf[cmdline_size] = '\0'; > + for (ssize_t i = 0; i < cmdline_size; i++) { > + if (buf[i] == '\0') > + buf[i] = ' '; > + else if (!isprint((unsigned char)buf[i])) > + buf[i] = '.'; > + } > + if (printed == 0) > + printed += scnprintf(msg, size, > + "Possible processes:\n"); > + > + printed += scnprintf(msg + printed, size - printed, > + "%s %s\n", proc_entry->d_name, buf); > + break; > + } > } > } > closedir(fd_dir); > @@ -4285,7 +4338,9 @@ int evsel__open_strerror(struct evsel *evsel, struct target *target, > msg, size, > "The PMU %s counters are busy and in use by another process.\n", > evsel->pmu ? evsel->pmu->name : ""); > - return printed + dump_perf_event_processes(msg + printed, size - printed); > + return printed + dump_perf_event_processes(evsel, > + msg + printed, > + size - printed); > break; > case EINVAL: > if (evsel->core.attr.sample_type & PERF_SAMPLE_CODE_PAGE_SIZE && perf_missing_features.code_page_size) > -- > 2.54.0.1013.g208068f2d8-goog > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-06-09 15:58 ` Ian Rogers @ 2026-06-09 17:20 ` Arnaldo Carvalho de Melo 2026-09-14 1:44 ` Arnaldo Carvalho de Melo 0 siblings, 1 reply; 10+ messages in thread From: Arnaldo Carvalho de Melo @ 2026-06-09 17:20 UTC (permalink / raw) To: Ian Rogers Cc: Chun-Tse Shao, Namhyung Kim, Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Tue, Jun 09, 2026 at 08:58:03AM -0700, Ian Rogers wrote: > On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > > > It parses fdinfo with PMU type, comparing with the event which failed to > > open, and report the processes causing EBUSY error. > > > > Testing cycles and intel_pt// > > > > $ ./perf stat -e cycles & > > [1] 55569 > > $ ./perf stat -e intel_pt// & > > [2] 55683 > > $ ./perf stat -e intel_pt// > > Error: > > The PMU intel_pt counters are busy and in use by another process. > > Possible processes: > > 55683 ./perf stat -e intel_pt// > > > > Only perf with intel_pt was reported. > > > > Reviewed-by: Ian Rogers <irogers@google.com> > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > Assisted-by: Gemini:gemini-3.1-pro-preview > > Arnaldo, as the kernel piece of this landed (thanks Peter!) could we > land the tool part too? Thanks for pointing this out to me, I'll do some housekeeping and process this. - Arnaldo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-06-09 17:20 ` Arnaldo Carvalho de Melo @ 2026-09-14 1:44 ` Arnaldo Carvalho de Melo 2026-09-14 20:29 ` Chun-Tse Shao 0 siblings, 1 reply; 10+ messages in thread From: Arnaldo Carvalho de Melo @ 2026-09-14 1:44 UTC (permalink / raw) To: Ian Rogers Cc: Chun-Tse Shao, Namhyung Kim, Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Tue, Jun 09, 2026 at 02:20:43PM -0300, Arnaldo Carvalho de Melo wrote: > On Tue, Jun 09, 2026 at 08:58:03AM -0700, Ian Rogers wrote: > > On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > > > > > It parses fdinfo with PMU type, comparing with the event which failed to > > > open, and report the processes causing EBUSY error. > > > > > > Testing cycles and intel_pt// > > > > > > $ ./perf stat -e cycles & > > > [1] 55569 > > > $ ./perf stat -e intel_pt// & > > > [2] 55683 > > > $ ./perf stat -e intel_pt// > > > Error: > > > The PMU intel_pt counters are busy and in use by another process. > > > Possible processes: > > > 55683 ./perf stat -e intel_pt// > > > > > > Only perf with intel_pt was reported. > > > > > > Reviewed-by: Ian Rogers <irogers@google.com> > > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > > Assisted-by: Gemini:gemini-3.1-pro-preview > > > > Arnaldo, as the kernel piece of this landed (thanks Peter!) could we > > land the tool part too? > > Thanks for pointing this out to me, I'll do some housekeeping and > process this. I think this hasn't landed, I tried to find the userland part of v8 but didn't manage to, can you please point it to me? - Arnaldo ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-09-14 1:44 ` Arnaldo Carvalho de Melo @ 2026-09-14 20:29 ` Chun-Tse Shao 2026-09-15 18:54 ` Ian Rogers 0 siblings, 1 reply; 10+ messages in thread From: Chun-Tse Shao @ 2026-09-14 20:29 UTC (permalink / raw) To: Arnaldo Carvalho de Melo Cc: Ian Rogers, Namhyung Kim, Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Sun, Sep 13, 2026 at 6:44 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > On Tue, Jun 09, 2026 at 02:20:43PM -0300, Arnaldo Carvalho de Melo wrote: > > On Tue, Jun 09, 2026 at 08:58:03AM -0700, Ian Rogers wrote: > > > On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > > > > > > > It parses fdinfo with PMU type, comparing with the event which failed to > > > > open, and report the processes causing EBUSY error. > > > > > > > > Testing cycles and intel_pt// > > > > > > > > $ ./perf stat -e cycles & > > > > [1] 55569 > > > > $ ./perf stat -e intel_pt// & > > > > [2] 55683 > > > > $ ./perf stat -e intel_pt// > > > > Error: > > > > The PMU intel_pt counters are busy and in use by another process. > > > > Possible processes: > > > > 55683 ./perf stat -e intel_pt// > > > > > > > > Only perf with intel_pt was reported. > > > > > > > > Reviewed-by: Ian Rogers <irogers@google.com> > > > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > > > Assisted-by: Gemini:gemini-3.1-pro-preview > > > > > > Arnaldo, as the kernel piece of this landed (thanks Peter!) could we > > > land the tool part too? > > > > Thanks for pointing this out to me, I'll do some housekeeping and > > process this. > > I think this hasn't landed, I tried to find the userland part of v8 but > didn't manage to, can you please point it to me? > > - Arnaldo Hi Arnaldo, Thanks for taking care this. The link to lkml for this userland part is: https://lore.kernel.org/all/20260602181349.3969429-2-ctshao@google.com/ The kernel part (https://lore.kernel.org/all/20260602181349.3969429-1-ctshao@google.com/) was merged by Peter Zijlstra and I can see a tip-bot replied on it. -CT ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-09-14 20:29 ` Chun-Tse Shao @ 2026-09-15 18:54 ` Ian Rogers 2026-09-15 20:52 ` Chun-Tse Shao 0 siblings, 1 reply; 10+ messages in thread From: Ian Rogers @ 2026-09-15 18:54 UTC (permalink / raw) To: Chun-Tse Shao Cc: Arnaldo Carvalho de Melo, Namhyung Kim, Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Mon, Sep 14, 2026 at 1:30 PM Chun-Tse Shao <ctshao@google.com> wrote: > > On Sun, Sep 13, 2026 at 6:44 PM Arnaldo Carvalho de Melo > <acme@kernel.org> wrote: > > > > On Tue, Jun 09, 2026 at 02:20:43PM -0300, Arnaldo Carvalho de Melo wrote: > > > On Tue, Jun 09, 2026 at 08:58:03AM -0700, Ian Rogers wrote: > > > > On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > > > > > > > > > It parses fdinfo with PMU type, comparing with the event which failed to > > > > > open, and report the processes causing EBUSY error. > > > > > > > > > > Testing cycles and intel_pt// > > > > > > > > > > $ ./perf stat -e cycles & > > > > > [1] 55569 > > > > > $ ./perf stat -e intel_pt// & > > > > > [2] 55683 > > > > > $ ./perf stat -e intel_pt// > > > > > Error: > > > > > The PMU intel_pt counters are busy and in use by another process. > > > > > Possible processes: > > > > > 55683 ./perf stat -e intel_pt// > > > > > > > > > > Only perf with intel_pt was reported. > > > > > > > > > > Reviewed-by: Ian Rogers <irogers@google.com> > > > > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > > > > Assisted-by: Gemini:gemini-3.1-pro-preview > > > > > > > > Arnaldo, as the kernel piece of this landed (thanks Peter!) could we > > > > land the tool part too? > > > > > > Thanks for pointing this out to me, I'll do some housekeeping and > > > process this. > > > > I think this hasn't landed, I tried to find the userland part of v8 but > > didn't manage to, can you please point it to me? > > > > - Arnaldo > > Hi Arnaldo, > > Thanks for taking care this. The link to lkml for this userland part > is: https://lore.kernel.org/all/20260602181349.3969429-2-ctshao@google.com/ Hi CT, Would it be possible to rebase and resend the tool part as a v9? This will also trigger the Sashiko review, which would be nice to have. Thanks, Ian > The kernel part > (https://lore.kernel.org/all/20260602181349.3969429-1-ctshao@google.com/) > was merged by Peter Zijlstra and I can see a tip-bot replied on it. > > -CT ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY 2026-09-15 18:54 ` Ian Rogers @ 2026-09-15 20:52 ` Chun-Tse Shao 0 siblings, 0 replies; 10+ messages in thread From: Chun-Tse Shao @ 2026-09-15 20:52 UTC (permalink / raw) To: Ian Rogers Cc: Arnaldo Carvalho de Melo, Namhyung Kim, Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Tue, Sep 15, 2026 at 11:54 AM Ian Rogers <irogers@google.com> wrote: > > On Mon, Sep 14, 2026 at 1:30 PM Chun-Tse Shao <ctshao@google.com> wrote: > > > > On Sun, Sep 13, 2026 at 6:44 PM Arnaldo Carvalho de Melo > > <acme@kernel.org> wrote: > > > > > > On Tue, Jun 09, 2026 at 02:20:43PM -0300, Arnaldo Carvalho de Melo wrote: > > > > On Tue, Jun 09, 2026 at 08:58:03AM -0700, Ian Rogers wrote: > > > > > On Tue, Jun 2, 2026 at 11:13 AM Chun-Tse Shao <ctshao@google.com> wrote: > > > > > > > > > > > > It parses fdinfo with PMU type, comparing with the event which failed to > > > > > > open, and report the processes causing EBUSY error. > > > > > > > > > > > > Testing cycles and intel_pt// > > > > > > > > > > > > $ ./perf stat -e cycles & > > > > > > [1] 55569 > > > > > > $ ./perf stat -e intel_pt// & > > > > > > [2] 55683 > > > > > > $ ./perf stat -e intel_pt// > > > > > > Error: > > > > > > The PMU intel_pt counters are busy and in use by another process. > > > > > > Possible processes: > > > > > > 55683 ./perf stat -e intel_pt// > > > > > > > > > > > > Only perf with intel_pt was reported. > > > > > > > > > > > > Reviewed-by: Ian Rogers <irogers@google.com> > > > > > > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > > > > > > Assisted-by: Gemini:gemini-3.1-pro-preview > > > > > > > > > > Arnaldo, as the kernel piece of this landed (thanks Peter!) could we > > > > > land the tool part too? > > > > > > > > Thanks for pointing this out to me, I'll do some housekeeping and > > > > process this. > > > > > > I think this hasn't landed, I tried to find the userland part of v8 but > > > didn't manage to, can you please point it to me? > > > > > > - Arnaldo > > > > Hi Arnaldo, > > > > Thanks for taking care this. The link to lkml for this userland part > > is: https://lore.kernel.org/all/20260602181349.3969429-2-ctshao@google.com/ > > Hi CT, > > Would it be possible to rebase and resend the tool part as a v9? This > will also trigger the Sashiko review, which would be nice to have. > > Thanks, > Ian Thank you Ian, please check lore.kernel.org/20260915204951.2935261-2-ctshao@google.com for the rebased v9 patch. -CT > > > The kernel part > > (https://lore.kernel.org/all/20260602181349.3969429-1-ctshao@google.com/) > > was merged by Peter Zijlstra and I can see a tip-bot replied on it. > > > > -CT ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v8 1/2] perf: Reveal PMU type in fdinfo 2026-06-02 18:13 [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Chun-Tse Shao 2026-06-02 18:13 ` [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao @ 2026-06-04 9:21 ` Peter Zijlstra 2026-06-09 8:21 ` [tip: perf/core] " tip-bot2 for Chun-Tse Shao 2 siblings, 0 replies; 10+ messages in thread From: Peter Zijlstra @ 2026-06-04 9:21 UTC (permalink / raw) To: Chun-Tse Shao Cc: Ian Rogers, Ingo Molnar, Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter, James Clark, Thomas Falcon, linux-kernel, linux-perf-users On Tue, Jun 02, 2026 at 11:13:48AM -0700, Chun-Tse Shao wrote: > It gives useful info on knowing which PMUs are reserved by this process. > Also add config which would be useful. > Testing cycles: > > $ ./perf stat -e cycles & > $ cat /proc/`pidof perf`/fdinfo/3 > pos: 0 > flags: 02000002 > mnt_id: 16 > ino: 3081 > perf_event_attr.type: 0 > perf_event_attr.config: 0x0 > perf_event_attr.config1: 0x0 > perf_event_attr.config2: 0x0 > perf_event_attr.config3: 0x0 > perf_event_attr.config4: 0x0 > > Testing L1-dcache-load-misses: > > $ ./perf stat -e L1-dcache-load-misses & > $ cat /proc/`pidof perf`/fdinfo/3 > pos: 0 > flags: 02000002 > mnt_id: 16 > ino: 1072 > perf_event_attr.type: 3 > perf_event_attr.config: 0x10000 > perf_event_attr.config1: 0x0 > perf_event_attr.config2: 0x0 > perf_event_attr.config3: 0x0 > perf_event_attr.config4: 0x0 > > Reviewed-by: Ian Rogers <irogers@google.com> > Signed-off-by: Chun-Tse Shao <ctshao@google.com> > Assisted-by: Gemini:gemini-3.1-pro-preview > --- Yeah, I suppose I'll take this. But I'm not sure about the wording here. PMUs aren't really reserved as such. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [tip: perf/core] perf: Reveal PMU type in fdinfo 2026-06-02 18:13 [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Chun-Tse Shao 2026-06-02 18:13 ` [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao 2026-06-04 9:21 ` [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Peter Zijlstra @ 2026-06-09 8:21 ` tip-bot2 for Chun-Tse Shao 2 siblings, 0 replies; 10+ messages in thread From: tip-bot2 for Chun-Tse Shao @ 2026-06-09 8:21 UTC (permalink / raw) To: linux-tip-commits Cc: Chun-Tse Shao, Peter Zijlstra (Intel), Ian Rogers, x86, linux-kernel The following commit has been merged into the perf/core branch of tip: Commit-ID: 2369ce0f16b89e3d85c9683c06eb104545999378 Gitweb: https://git.kernel.org/tip/2369ce0f16b89e3d85c9683c06eb104545999378 Author: Chun-Tse Shao <ctshao@google.com> AuthorDate: Tue, 02 Jun 2026 11:13:48 -07:00 Committer: Peter Zijlstra <peterz@infradead.org> CommitterDate: Thu, 04 Jun 2026 11:38:38 +02:00 perf: Reveal PMU type in fdinfo It gives useful info on knowing which PMUs are reserved by this process. Also add config which would be useful. Testing cycles: $ ./perf stat -e cycles & $ cat /proc/`pidof perf`/fdinfo/3 pos: 0 flags: 02000002 mnt_id: 16 ino: 3081 perf_event_attr.type: 0 perf_event_attr.config: 0x0 perf_event_attr.config1: 0x0 perf_event_attr.config2: 0x0 perf_event_attr.config3: 0x0 perf_event_attr.config4: 0x0 Testing L1-dcache-load-misses: $ ./perf stat -e L1-dcache-load-misses & $ cat /proc/`pidof perf`/fdinfo/3 pos: 0 flags: 02000002 mnt_id: 16 ino: 1072 perf_event_attr.type: 3 perf_event_attr.config: 0x10000 perf_event_attr.config1: 0x0 perf_event_attr.config2: 0x0 perf_event_attr.config3: 0x0 perf_event_attr.config4: 0x0 Signed-off-by: Chun-Tse Shao <ctshao@google.com> Assisted-by: Gemini:gemini-3.1-pro-preview Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Ian Rogers <irogers@google.com> Link: https://patch.msgid.link/20260602181349.3969429-1-ctshao@google.com --- kernel/events/core.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index 7935d56..95d806b 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -58,6 +58,7 @@ #include <linux/percpu-rwsem.h> #include <linux/unwind_deferred.h> #include <linux/kvm_types.h> +#include <linux/seq_file.h> #include "internal.h" @@ -7546,6 +7547,33 @@ static int perf_fasync(int fd, struct file *filp, int on) return 0; } +static void perf_show_fdinfo(struct seq_file *m, struct file *f) +{ + struct perf_event *event = f->private_data; + struct perf_event_context *ctx; + struct mutex *child_mutex; + + ctx = perf_event_ctx_lock(event); + child_mutex = event->parent ? &event->parent->child_mutex : &event->child_mutex; + mutex_lock(child_mutex); + + seq_printf(m, "perf_event_attr.type:\t%u\n", event->orig_type); + if (event->pmu) + seq_printf(m, "pmu_type:\t%u\n", event->pmu->type); + seq_printf(m, "perf_event_attr.config:\t0x%llx\n", (unsigned long long)event->attr.config); + seq_printf(m, "perf_event_attr.config1:\t0x%llx\n", + (unsigned long long)event->attr.config1); + seq_printf(m, "perf_event_attr.config2:\t0x%llx\n", + (unsigned long long)event->attr.config2); + seq_printf(m, "perf_event_attr.config3:\t0x%llx\n", + (unsigned long long)event->attr.config3); + seq_printf(m, "perf_event_attr.config4:\t0x%llx\n", + (unsigned long long)event->attr.config4); + + mutex_unlock(child_mutex); + perf_event_ctx_unlock(event, ctx); +} + static const struct file_operations perf_fops = { .release = perf_release, .read = perf_read, @@ -7554,6 +7582,7 @@ static const struct file_operations perf_fops = { .compat_ioctl = perf_compat_ioctl, .mmap = perf_mmap, .fasync = perf_fasync, + .show_fdinfo = perf_show_fdinfo, }; /* ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-09-15 20:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-06-02 18:13 [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Chun-Tse Shao 2026-06-02 18:13 ` [PATCH v8 2/2] perf evsel: Find process with busy PMUs for EBUSY Chun-Tse Shao 2026-06-09 15:58 ` Ian Rogers 2026-06-09 17:20 ` Arnaldo Carvalho de Melo 2026-09-14 1:44 ` Arnaldo Carvalho de Melo 2026-09-14 20:29 ` Chun-Tse Shao 2026-09-15 18:54 ` Ian Rogers 2026-09-15 20:52 ` Chun-Tse Shao 2026-06-04 9:21 ` [PATCH v8 1/2] perf: Reveal PMU type in fdinfo Peter Zijlstra 2026-06-09 8:21 ` [tip: perf/core] " tip-bot2 for Chun-Tse Shao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®