Re: [PATCH v2] perf/core: Fix ITRACE start suppression for inherited events

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] perf/core: data race on attach_state via cross-context RMW
--

commit d3d316cfe645aab199ffb03f9db1a44478297ef1
Author: Leo Yan <leo.yan@arm.com>
Date:   Tue Sep 29 15:08:32 2026 +0000

perf/core: Fix ITRACE start suppression for inherited events

This commit modifies perf_event_itrace_started() to apply the
PERF_ATTACH_ITRACE flag to the parent event instead of the child event for
inherited events. This ensures that the setter and checker use the same
event to prevent redundant ITRACE_START records on subsequent schedule-ins.

Closes: https://lore.kernel.org/linux-perf-users/20260901164705.042781F000E9@smtp.kernel.org/
Fixes: 9a6694cfa239 ("perf/x86/intel/pt: Do not force sync packets on every schedule-in")

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 634d2ccbab82d..85d924cce387f 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10568,6 +10568,9 @@ void perf_event_text_poke(const void *addr, const void *old_bytes,
>  
>  void perf_event_itrace_started(struct perf_event *event)
>  {
> +	if (event->parent)
> +		event = event->parent;
> +
>  	WRITE_ONCE(event->attach_state, event->attach_state | PERF_ATTACH_ITRACE);

[Severity: High]
Does this introduce a cross-context read-modify-write data race on the shared
parent event's attach_state?

perf_event_itrace_started() is called from the PMU schedule-in path, holding
only the child's ctx->lock. It performs a lockless, non-atomic update on the
parent's attach_state.

Concurrently, the parent event might be undergoing teardown and modifying the
same attach_state field using non-atomic bitwise clears while holding the
parent's ctx->lock:

kernel/events/core.c:list_del_event() {
    ...
    event->attach_state &= ~PERF_ATTACH_CONTEXT;
    ...
}

Another concurrent update to the parent's attach_state occurs in
perf_group_detach():

kernel/events/core.c:perf_group_detach() {
    ...
    event->attach_state &= ~PERF_ATTACH_GROUP;
    ...
}

Because child events remain fully active and are detached only after the parent
is removed from its context, a child event can schedule in and race with the
parent's teardown.

Could this RMW race silently overwrite and resurrect bits that the parent
teardown just cleared?

If PERF_ATTACH_CONTEXT is resurrected, it seems it would bypass the
double-detach protection in list_del_event(), which is legitimately called
twice during exit() and close(). Would this result in integer underflow on
ctx->nr_events and list corruption from double list removals?

>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929-perf_core_itrace_start_fix_inherit_event-v2-1-9361a946ed56@arm.com?part=1