Re: [PATCH v4 0/3] perf: Fix SIGCHLD vs pause() race with short-lived workloads

[Arnaldo Carvalho de Melo]

On Wed, May 20, 2026 at 10:20:14AM +0000, Swapnil Sapkal wrote:
> Several perf subcommands (sched stats, lock contention) use the pattern
> of forking a workload child, calling evlist__start_workload() to uncork
> it, and then calling pause() to wait for a signal (typically SIGCHLD
> when the child exits, or SIGINT/SIGTERM from the user).
> 
> This pattern has a race condition: if the workload is very short-lived,
> the child can exit and deliver SIGCHLD in the window between
> evlist__start_workload() and pause(). Since pause() only returns when a
> signal is received *while the process is suspended*, and SIGCHLD has
> already been delivered and handled by the empty sighandler(), pause()
> blocks indefinitely.
> 
> The fix replaces pause() with a simpler approach:
> 
>  - The signal handler now sets a 'volatile sig_atomic_t done' flag
>    to record delivery.  The flag is reset before handler registration
>    so that a signal arriving during the setup phase is not discarded.
> 
>  - Replace pause() with a unified loop:
> 
>        while (!done) {
>            if (argc && waitpid(evlist->workload.pid, NULL, WNOHANG) > 0)
>                break;
>            sleep(1);
>        }
> 
>    This handles both workload mode (child exit detected via waitpid)
>    and system-wide mode (user sends SIGINT/SIGTERM setting done).
>    Using WNOHANG avoids the SA_RESTART problem where a blocking
>    waitpid() would auto-restart and ignore the done flag if the child
>    doesn't exit on signal.
> 
> Three call sites are affected across two files:
>   - perf_sched__schedstat_record() in builtin-sched.c
>   - perf_sched__schedstat_live()   in builtin-sched.c
>   - __cmd_contention()             in builtin-lock.c
> 
> The two pause() sites in builtin-kwork.c are NOT affected because they
> do not register SIGCHLD or fork workload children; they only wait for
> user-initiated SIGINT/SIGTERM.

Thanks, applied to perf-tools-next, for v7.2.

- Arnaldo