Linux Perf Users
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Haris Okanovic" <harisokn@amazon.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/2] perf/arm-cmn: Don't schedule events on a CPU which no longer owns the PMU
Date: Wed, 30 Sep 2026 23:25:03 +0000	[thread overview]
Message-ID: <20260930232503.883BB1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930231127.3094040-2-harisokn@amazon.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] perf/arm-cmn: stranded event in old CPU context due to migration race
--

commit 79c6912babc23948df500b06efb6265f5c3afcf3
Author: Haris Okanovic <harisokn@amazon.com>

perf/arm-cmn: Don't schedule events on a CPU which no longer owns the PMU

perf_event_open() can latch cmn->cpu and then install the event after a
migration has already moved the PMU. The driver has no locking -- it
relies on all events living in one CPU's context -- so such an event
races the owning CPU and can corrupt the shared DTC and DTM state,
giving wrong counts. arm_cmn_event_add() now rejects an event which is
not on the owning CPU.

> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
> index b162de3d9d169..0a35a692241dd 100644
> --- a/drivers/perf/arm-cmn.c
> +++ b/drivers/perf/arm-cmn.c
> @@ -2098,6 +2098,9 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
>  	enum cmn_node_type type = CMN_EVENT_TYPE(event);
>  	unsigned int input_sel, i = 0;
>  
> +	if (cmn->cpu != smp_processor_id())
> +		return -ENOENT;
> +

[Severity: Medium]
While this rejection successfully prevents data corruption during a race with
PMU migration, does it leave the newly created event permanently stranded?

If arm_cmn_migrate() runs after perf_event_open() reads cmn->cpu without
taking locks, but before perf_install_in_context() completes, the event will
land in the pre-migration CPU context. Because smp_processor_id() no longer
matches cmn->cpu, this check returns -ENOENT. 

This leaves the event marked INACTIVE by the perf core and permanently stranded
on the wrong CPU context, where it will silently fail to collect counts without
crashing.

Could this race be handled differently so the event gets correctly migrated or
rejected during creation, rather than silently failing to activate?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930231127.3094040-1-harisokn@amazon.com?part=1

  reply	other threads:[~2026-09-30 23:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30 23:11 [PATCH v2 0/2] perf/arm-cmn: Allow userspace to select the PMU's CPU Haris Okanovic
2026-09-30 23:11 ` [PATCH v2 1/2] perf/arm-cmn: Don't schedule events on a CPU which no longer owns the PMU Haris Okanovic
2026-09-30 23:25   ` sashiko-bot [this message]
2026-09-30 23:11 ` [PATCH v2 2/2] perf/arm-cmn: Allow userspace to select the PMU's CPU Haris Okanovic
2026-09-30 23:24   ` 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=20260930232503.883BB1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=harisokn@amazon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox