From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 325BC3793CA; Tue, 12 May 2026 15:00:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778598009; cv=none; b=YsS9sQhX38ZIlvZrgsN/1GQwR+EI0yer3z5zZN263fbbfhOmCNRjjd/C3hHNZ0bWqdPo2XPQRfdp8eR/e4aBHai4ai0SU0HLN8AVJyyM/Nin19ldaxG1f4S3VpWGkDL4a7pGzTgqSflggkMtm5eel32kteQ3ixnHec1UreLLeDg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778598009; c=relaxed/simple; bh=ANmG2eoNDdy0Z3P7hT8l+nQemTPKyd01Er806m3PJPQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=rXAv2jh8OfJYrJgNVR8q/r+XWw4iIFG0Jgsb4LnQv6EgNCv6UIKdRMWkeFaStVjOOCNWE4h8U4ZOSmqEYHXq62HlRzbbaIOBzwTVC3sNumuAF3rxG6DEgPjVhbnAALLC0GXxgBq/3NezbdiBeJFbpaCdla223fGtnnrEnF/x1KQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=CG2UisA4; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="CG2UisA4" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 27CA62309; Tue, 12 May 2026 08:00:02 -0700 (PDT) Received: from e132581.arm.com (e132581.arm.com [10.1.196.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E7C0D3F836; Tue, 12 May 2026 08:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778598007; bh=ANmG2eoNDdy0Z3P7hT8l+nQemTPKyd01Er806m3PJPQ=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=CG2UisA4llzQ08ElJY3BHN+xt4lMXMybrNHzIJOv3dhOpAWykgpzLJX8oKZGJVt10 lJ412lxOFLvcnP9CHwr842mRkFJ4iuUDmp50p1sqZhf37KMOjIISdNTRdEuovJoMt2 8OZRb1ktv2nACRyvZfqz6SJh+fFjhXq/mjsrLYvw= From: Leo Yan Date: Tue, 12 May 2026 15:59:53 +0100 Subject: [PATCH 2/2] Revert "perf: Fix the POLL_HUP delivery breakage" Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260512-arm_cs_clean_perf_handle-v1-2-75ff373ecd22@arm.com> References: <20260512-arm_cs_clean_perf_handle-v1-0-75ff373ecd22@arm.com> In-Reply-To: <20260512-arm_cs_clean_perf_handle-v1-0-75ff373ecd22@arm.com> To: Peter Zijlstra , Ingo Molnar , Shuah Khan , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Sumanth Korikkar Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-perf-users@vger.kernel.org, Leo Yan X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1778597999; l=1675; i=leo.yan@arm.com; s=20250604; h=from:subject:message-id; bh=ANmG2eoNDdy0Z3P7hT8l+nQemTPKyd01Er806m3PJPQ=; b=CEh7KUiK2oHsd1UpXjvxGBTdgCQ2vzc8jaAeM5SDMkEmYZL8W7oXeQoj9qgP1FvmkYV3gKU+A 9OCkYwg6zuSCV6DYHUiYFsJq1d8ieGnSExU4yO8vDPkgwryu+Wn7awf X-Developer-Key: i=leo.yan@arm.com; a=ed25519; pk=k4BaDbvkCXzBFA7Nw184KHGP5thju8lKqJYIrOWxDhI= This reverts commit 18dbcbfabfffc4a5d3ea10290c5ad27f22b0d240. The original issue was reported in [1], it shared a test program with SIGIO. Since SIGIO is a standard signal, multiple notifications can be coalesced, so userspace may miss a signal even though the signal was generated by the event core. Using the Ftrace signal tracepoints on arm64 shows that POLL_HUP is generated, but the corresponding delivery trace event ("signal_deliver") may be absent when SIGIO is used. In contrast, the kselftest refresh_signal demonstrates that POLL_HUP delivery is reliable when using a real-time signal, and the test passes without the extra pmu->stop() call introduced by commit 18dbcbfabfff. When the refresh limit reaches zero, __perf_event_overflow() already calls perf_event_disable_inatomic(), which schedules the event disable through irq_work. Calling the PMU stop callback directly here is redundant and unrelated to signal delivery. Remove the extra stop callback. [1] https://lore.kernel.org/lkml/aICYAqM5EQUlTqtX@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com/ Signed-off-by: Leo Yan --- kernel/events/core.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index 7935d5663944ee1cbaf38cf8018c3347635e8d31..7d98a56cd91c47e6ac0e4f8ace1ab494ba2b0501 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -10750,7 +10750,6 @@ 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) { -- 2.34.1