linux-kernel - Re: [PATCH V4 07/16] s390/perf: Remove driver-specific throttle support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aJn33wiBoMMToyrY@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com>
Date: Mon, 11 Aug 2025 16:02:07 +0200
From: Sumanth Korikkar <sumanthk@...ux.ibm.com>
To: "Liang, Kan" <kan.liang@...ux.intel.com>
Cc: peterz@...radead.org, mingo@...hat.com, namhyung@...nel.org,
        irogers@...gle.com, mark.rutland@....com, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org, eranian@...gle.com,
        ctshao@...gle.com, tmricht@...ux.ibm.com, leo.yan@....com,
        linux-s390@...r.kernel.org
Subject: Re: [PATCH V4 07/16] s390/perf: Remove driver-specific throttle
 support

> >> Hi all,
> >>
> >> This seems to break POLL_HUP delivery to userspace - when event_limit reaches 0
> >>
> >> From perf_event_open man page:
> >> PERF_EVENT_IOC_REFRESH
> >>               Non-inherited overflow counters can use this to enable a
> >>               counter for a number of overflows specified by the
> >>               argument, after which it is disabled.  Subsequent calls of
> >>               this ioctl add the argument value to the current count.  An
> >>               overflow notification with POLL_IN set will happen on each
> >>               overflow until the count reaches 0; when that happens a
> >>               notification with POLL_HUP set is sent and the event is
> >>               disabled.
> >>
> >> When the event_limit reaches 0, the POLL_HUP signal is expected to be
> >> sent. Prior to this patch, an explicit call to event->stop() was made,
> >> which may have contributed to ensuring that the POLL_HUP signal was
> >> ultimately delivered. However, after  this change, I often did not
> >> observe the POLL_HUP signal being delivered as expected in the end
> 
> The event_limit case also returns 1. I missed it when fixing the
> throttle issue. :(
> 
> I didn't use the IOC_REFRESH before. According to the kernel code, it
> reschedules all the events of the event->pmu, when the ioctl is invoked.
> So we just need to move the event->pmu->stop() to the generic code as
> below. It should keep the behavior unchanged.
> 
> Could you please try the below fix?
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 14ae43694833..f492cbcd3bb6 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -10341,6 +10341,7 @@ static int __perf_event_overflow(struct
> perf_event *event,
>  		ret = 1;
>  		event->pending_kill = POLL_HUP;
>  		perf_event_disable_inatomic(event);
> +		event->pmu->stop(event, 0);
>  	}
> 
>  	if (event->attr.sigtrap) {
> 
> Thanks,
> Kan

Hi Kan,

The above fix works.

Tested-by: Sumanth Korikkar <sumanthk@...ux.ibm.com>

Thank you