All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ian Rogers" <irogers@google.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [RFC PATCH v2 5/9] perf pmu: Add perf_pmu__probe() for live capability probing
Date: Sat, 17 Oct 2026 19:18:15 +0000	[thread overview]
Message-ID: <sashiko-outbox-175776@kernel.org> (raw)
In-Reply-To: <20261017185442.2137623-6-irogers@google.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf pmu: select_probe_cpu() ignores task CPU affinity mask
--

commit a706bded05059ea05d5c1e851935d2f599c67616
Author: Ian Rogers <irogers@google.com>

perf pmu: Add perf_pmu__probe() for live capability probing

This commit adds struct perf_pmu::probed and perf_pmu__probe() to actively
probe live PMU capabilities via perf_event_open(), covering counting and
sampling modes, precise_ip levels, sample formats, privilege exclusion
modifiers, execution features, and event group size limits.

> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> index cd8211f872911..83c8d6f392ba9 100644
> --- a/tools/perf/util/pmu.c
> +++ b/tools/perf/util/pmu.c

[ ... ]

> @@ -2832,9 +2847,1219 @@ void perf_pmu__delete(struct perf_pmu *pmu)

[ ... ]

> +static int select_probe_cpu(const struct perf_pmu *pmu)
> +{
> +	struct perf_cpu_map *online = perf_cpu_map__new_online_cpus();
> +	int cpu = 0;
> +
> +	if (pmu->cpus && !perf_cpu_map__is_empty(pmu->cpus)) {
> +		int nr = perf_cpu_map__nr(pmu->cpus);
> +
> +		cpu = perf_cpu_map__cpu(pmu->cpus, 0).cpu;
> +		if (online) {
> +			for (int i = 0; i < nr; i++) {
> +				struct perf_cpu c = perf_cpu_map__cpu(pmu->cpus, i);
> +
> +				if (perf_cpu_map__has(online, c)) {
> +					cpu = c.cpu;
> +					break;
> +				}
> +			}
> +		}
> +	} else if (online && !perf_cpu_map__is_empty(online)) {
> +		cpu = perf_cpu_map__cpu(online, 0).cpu;
> +	}
> +
> +	perf_cpu_map__put(online);
> +	return cpu >= 0 ? cpu : 0;
> +}

[ ... ]

> +static void probe_group_limits(const struct perf_event_attr *attrs, size_t nr_attrs,
> +			       pid_t pid, int cpu, unsigned long flags,
> +			       int *max_open, bool *open_capped,
> +			       int *max_active, bool *active_capped)
> +{
> +	struct perf_event_attr leader_attr;
> +	int leader_fd;
> +	int fds[MAX_PROBE_GROUP_SIZE];
> +	int nr_followers = 0;
> +	bool has_time_read = true;
> +	bool active_ok = true;
> +	enum rlimit_action set_rlimit = NO_CHANGE;
> +	cpu_set_t saved_affinity, probe_affinity;
> +	bool affinity_changed = false;
> +
> +	*max_open = 0;
> +	*open_capped = false;
> +	*max_active = 0;
> +	*active_capped = false;
> +
> +	if (!attrs || nr_attrs == 0)
> +		return;
> +
> +	if (pid == 0 && cpu >= 0 && cpu < CPU_SETSIZE) {
> +		CPU_ZERO(&saved_affinity);
> +		if (sched_getaffinity(0, sizeof(saved_affinity), &saved_affinity) == 0) {
> +			CPU_ZERO(&probe_affinity);
> +			CPU_SET(cpu, &probe_affinity);
> +			if (sched_setaffinity(0, sizeof(probe_affinity), &probe_affinity) == 0)
> +				affinity_changed = true;
> +		}
> +	}

[Severity: Medium]
What happens in probe_group_limits() when perf runs inside a cgroup cpuset
(such as a container or a systemd unit with AllowedCPUs=) that excludes the
first online CPU of a PMU?

In select_probe_cpu(), the probe CPU is chosen as the first online CPU in
pmu->cpus (or online) without checking whether that CPU is in the calling
thread's allowed affinity mask via sched_getaffinity().

For non-uncore PMUs, try_open_attr_variants() opens events with pid = 0 and
cpu = pmu_cpu, which sys_perf_event_open() allows even when pmu_cpu is
outside the task's cpuset. However, when probe_group_limits() then tries to
pin the calling thread to cpu with sched_setaffinity(), it fails with -EINVAL.

When check_group_active() subsequently enables the (pid = 0, cpu = pmu_cpu)
group via PERF_EVENT_IOC_ENABLE and spins in userspace on a different CPU,
the kernel sets the event to PERF_EVENT_STATE_INACTIVE (incrementing
TOTAL_TIME_ENABLED), while event_filter_match() prevents scheduling it onto
the PMU because event->cpu != smp_processor_id(). As a result,
TOTAL_TIME_RUNNING stays 0 (delta_run != delta_ena), check_group_active()
returns false even for a single event, and max_active_group_size and
max_active_gp_group_size are reported as 0.

Should select_probe_cpu() prefer an online CPU that is also present in the
calling thread's sched_getaffinity() mask when available?

[ ... ]

> +	leader_attr = attrs[0];
> +	leader_attr.disabled = 1;
> +	leader_attr.read_format = PERF_FORMAT_TOTAL_TIME_ENABLED | PERF_FORMAT_TOTAL_TIME_RUNNING;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017185442.2137623-1-irogers@google.com?part=5

  reply	other threads:[~2026-10-17 19:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16 21:32 [RFC PATCH v1 0/2] perf sysinfo: Add subcommand to probe and summarize PMU capabilities Ian Rogers
2026-10-16 21:32 ` [RFC PATCH v1 1/2] perf pmus: Add PMU environment loading and live capability probing Ian Rogers
2026-10-16 21:56   ` sashiko-bot
2026-10-16 21:32 ` [RFC PATCH v1 2/2] perf sysinfo: Add sysinfo subcommand, documentation, and test Ian Rogers
2026-10-16 21:45   ` sashiko-bot
2026-10-17 18:54 ` [RFC PATCH v2 0/9] perf sysinfo: Add subcommand to probe and summarize PMU capabilities Ian Rogers
2026-10-17 18:54   ` [RFC PATCH v2 1/9] perf pmu: Add from_env parameter to perf_pmu__init() Ian Rogers
2026-10-17 19:06     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 2/9] perf pmus: Add perf_pmus__read_from_env() Ian Rogers
2026-10-17 19:15     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 3/9] perf pmus: Expose duplicate uncore PMU scanning helpers Ian Rogers
2026-10-17 18:58     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 4/9] perf mem-events: Expose PMU init and name formatting helpers Ian Rogers
2026-10-17 18:58     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 5/9] perf pmu: Add perf_pmu__probe() for live capability probing Ian Rogers
2026-10-17 19:18     ` sashiko-bot [this message]
2026-10-17 18:54   ` [RFC PATCH v2 6/9] perf pmu: Probe registers, memory events, rdpmc, and branch skid Ian Rogers
2026-10-17 19:15     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 7/9] perf sysinfo: Add sysinfo subcommand Ian Rogers
2026-10-17 19:14     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 8/9] perf docs: Add perf-sysinfo man page Ian Rogers
2026-10-17 18:57     ` sashiko-bot
2026-10-17 18:54   ` [RFC PATCH v2 9/9] perf test: Add perf sysinfo shell test Ian Rogers
2026-10-17 18:58     ` sashiko-bot

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=sashiko-outbox-175776@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=irogers@google.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.