Re: [PATCH] s390/pai: Prevent ioctl(PERF_EVENT_IOC_REFRESH)

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unprotected modification of core perf_event state (pending_kill, event_limit) causes data races, dropped signals, and silently breaks the PERF_EVENT_IOC_REFRESH API.
--

commit ae843d6ca679921720078776be6911f36a1931c1
Author: Thomas Richter <tmricht@linux.ibm.com>

s390/pai: Prevent ioctl(PERF_EVENT_IOC_REFRESH)

This commit prevents ioctl(fd, PERF_EVENT_IOC_REFRESH, XXX) from taking effect
on PAI PMU events by clearing event->pending_kill and event->event_limit. The
intention is to prevent counter resets that conflict with the schedule-out
readouts these PMUs are designed for.

> diff --git a/arch/s390/kernel/perf_pai.c b/arch/s390/kernel/perf_pai.c
> index cdb8006220ca0..e43b2f1c94471 100644
> --- a/arch/s390/kernel/perf_pai.c
> +++ b/arch/s390/kernel/perf_pai.c
> @@ -658,6 +658,8 @@ static void pai_have_sample(struct perf_event *event, struct pai_map *cpump)
>  
>  	if (!event)		/* No event active */
>  		return;
> +	event->pending_kill = 0;	/* prevent ioctl(IOC_REFRESH) */
> +	atomic_set(&event->event_limit, 0);

[Severity: High]
Does this unprotected modification of core perf_event state (pending_kill,
event_limit) cause data races, dropped signals, and silently break the
PERF_EVENT_IOC_REFRESH API?

Bypassing core perf locking rules to directly mutate event_limit and
pending_kill causes data races, silently drops pending SIGIO signals, and
breaks the API contract. The ioctl will return success, but userspace will
never receive the requested signal, leading to application hangs.

If a userspace application calls ioctl(fd, PERF_EVENT_IOC_REFRESH, N) on a
PAI event, and concurrently, a context switch calls pai_have_sample(),
writing to event_limit will race with atomic_add() in the core subsystem,
and clearing pending_kill will race with perf_event_wakeup().

PMU drivers should not directly mutate these core fields to implicitly break
an ioctl. This approach creates cross-CPU data races because it lacks the
synchronization (ctx->mutex for limits, irq_work execution order for signals)
used by the core subsystem. Any user with access to the PAI PMU can trigger
this state corruption.

>  	pp = &pai_pmu[PAI_PMU_IDX(event)];
>  	rawsize = pai_copy(cpump->save, cpump->area, pp,
>  			   (unsigned long *)PAI_SAVE_AREA(event),

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827064612.3161950-1-tmricht@linux.ibm.com?part=1