Re: [PATCH v7 01/14] alpha/perf: do not update an event that has no counter in alpha_pmu_del()

[Magnus Lindholm]

Hi Matt,

On Fri, Nov 6, 2026 at 5:30 AM Matt Turner <mattst88@xxxxxxxxx> wrote:
>
> alpha_pmu_add() puts a new event on the list with current_idx set to
> PMC_NO_INDEX, and alpha_pmu_enable() assigns the counter later, through
> maybe_change_configuration(). Alpha has no group transaction callbacks,
> so the core schedules a group with the PMU disabled for the whole
> group. When a sibling does not fit, for example because the counters
> are multiplexed between groups, group_sched_in() rolls back the events
> it already added by calling alpha_pmu_del() on them, before the PMU is
> enabled again.
>
> alpha_pmu_del() then passes idx == -1 to alpha_perf_event_update(),
> which indexes pmc_count_shift[], pmc_count_mask[] and pmc_max_period[]
> at -1, and it clears bit -1 of idx_mask, an undefined shift. On the
> EV67 PMU the entries before each array happen to make the computed
> delta zero, so the event's count survives, but only by luck of the
> struct layout.
>
> The event was never on a counter, so there is no count to absorb and no
> counter to turn off. Only remove it from the list.
>
> Fixes: 979f867191f8 ("alpha: implement HW performance events on the EV67 and later CPUs")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Matt Turner <mattst88@xxxxxxxxx>
> ---
>  arch/alpha/kernel/perf_event.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/alpha/kernel/perf_event.c b/arch/alpha/kernel/perf_event.c
> index a3eaab094ece..f77abeeb25b8 100644
> --- a/arch/alpha/kernel/perf_event.c
> +++ b/arch/alpha/kernel/perf_event.c
> @@ -506,11 +506,17 @@ static void alpha_pmu_del(struct perf_event *event, int flags)
>                                         cpuc->current_idx[j];
>                         }
>The guard looks correct: an event rolled back before counter
assignment must be removed without updating or disabling a counter.

Tested on my three-CPU EV67 AlphaServer ES40. A two-event group
multiplexed against a standalone event counted monotonically, with
scaled instruction counts agreeing within 1% on all three CPUs.

Reviewed-by: Magnus Lindholm <linmag7@xxxxxxxxx>
Tested-by: Magnus Lindholm <linmag7@xxxxxxxxx>
The guard looks correct: an event rolled back before counter
assignment must be removed without updating or disabling a counter.

Tested on my three-CPU EV67 AlphaServer ES40. A two-event group
multiplexed against a standalone event counted monotonically, with
scaled instruction counts agreeing within 1% on all three CPUs.

Reviewed-by: Magnus Lindholm <linmag7@xxxxxxxxx>
Tested-by: Magnus Lindholm <linmag7@xxxxxxxxx>
> -                       /* Absorb the final count and turn off the event. */
> -                       alpha_perf_event_update(event, hwc, idx, 0);
> -                       perf_event_update_userpage(event);
> +                       /*
> +                        * Absorb the final count and turn off the event,
> +                        * unless a failed group schedule rolled it back
> +                        * before it was given a counter.
> +                        */
> +                       if (idx != PMC_NO_INDEX) {
> +                               alpha_perf_event_update(event, hwc, idx, 0);
> +                               perf_event_update_userpage(event);
>
> -                       cpuc->idx_mask &= ~(1UL<<idx);
> +                               cpuc->idx_mask &= ~(1UL<<idx);
> +                       }
>                         cpuc->n_events--;
>                         break;
>                 }
>
> --
> 2.55.0
>

I think my reply to this patch was accidental off-list, sending it again:

The guard looks correct: an event rolled back before counter
assignment must be removed without updating or disabling a counter.

Tested on my three-CPU EV67 AlphaServer ES40. A two-event group
multiplexed against a standalone event counted monotonically, with
scaled instruction counts agreeing within 1% on all three CPUs.

Reviewed-by: Magnus Lindholm <linmag7@xxxxxxxxx>
Tested-by: Magnus Lindholm <linmag7@xxxxxxxxx>