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

[Thomas Richter <tmricht@linux.ibm.com>]

On 8/27/26 08:57, sashiko-bot@kernel.org wrote:
> 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.

A: The PERF_EVENT_IOC_REFRESH API is disabled on purpose. The PAI PMU
   relies on data collection on schedule out of a task. This is
   done by design. Invoking ioctl(fd, PERF_EVENT_IOC_REFRESH API, X)
   breaks this behavior and should be blocked.

   The modifications of members perf_event::event_limit and
   perf_event::pending_kill are protected. The invocation
   is triggered by the schedule out path and protected via
   perf_pmu_sched_task()
   +--> __perf_pmu_sched_task()
        +--> perf_ctx_lock()

   This locks the event and protects the states of the event.

> 
> 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().

This requires a common code change to block an ioctl(fd, PERF_EVENT_IOC_REFRESH, N)
similar to the PMU check_period call back function.

> 
> 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),
> 


-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
IBM Deutschland Research & Development GmbH

Vorsitzender des Aufsichtsrats: Wolfgang Wendt

Geschäftsführung: David Faller

Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294