Re: [PATCH v2] perf/core: Don't send SIGTRAP after exec removed the event

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 30, 2026 at 09:42:48AM -0500, Danish Khateeb wrote:
> A sigtrap event must also set remove_on_exec, so that its SIGTRAP never
> reaches a program after exec. But the signal is sent from task work,
> which only runs on the way back to user space. If the event overflows
> shortly before execve(), the task work can still be pending when the
> task enters execve(), and then runs when execve() returns. By then
> perf_event_exec() has removed the event and the new program has default
> signal handlers, so the SIGTRAP kills it.
> 
> The exec_stress test in the remove_on_exec selftest catches this and
> fails about half the time in a VM. A process that opens a sigtrap event
> on itself and then calls execve() is killed by SIGTRAP in 15% to 50% of
> runs, both on an AMD machine running v7.2 and in a VM, with or without
> close-on-exec on the event fd.
> 
> perf_event_exit_event() sets PERF_EVENT_STATE_EXIT when exec removes the
> event. If the event fd is close-on-exec and was the last reference to
> the file, exec also queues the file release as task work. Task work runs
> newest first, so perf_release() runs before the SIGTRAP work and moves
> the event on to PERF_EVENT_STATE_DEAD. Exit is already caught by the
> PF_EXITING check in perf_sigtrap(). So don't send the signal when the
> event state is PERF_EVENT_STATE_EXIT or lower, which means the event has
> been removed. That also covers PERF_EVENT_STATE_REVOKED, where the PMU
> is gone.
> 
> Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>

Is this the same problem as this one?

  https://patch.msgid.link/20260920075026.990582-1-luogengkun2@huawei.com