From: sashiko-bot@kernel.org
To: "Swapnil Sapkal" <swapnil.sapkal@amd.com>
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v2 1/3] perf sched stats: Fix SIGCHLD race in schedstat_record()
Date: Thu, 09 Apr 2026 16:51:02 +0000 [thread overview]
Message-ID: <20260409165102.E8A44C4CEF7@smtp.kernel.org> (raw)
In-Reply-To: <20260409162249.25581-2-swapnil.sapkal@amd.com>
Sashiko AI review found 1 potential issue(s):
- [Medium] The patch leaves a race window where early signals (like SIGINT) are lost, causing sigsuspend() to hang indefinitely.
--
commit 82e42f3b8c8062e3b83019c07f66b6e7199c4104
Author: Swapnil Sapkal <swapnil.sapkal@amd.com>
perf sched stats: Fix SIGCHLD race in schedstat_record()
This commit attempts to fix a SIGCHLD race in perf sched stats record by
replacing pause() with sigsuspend(). It blocks SIGCHLD, SIGINT, and SIGTERM
before starting the workload to ensure no signal is lost if the child exits
quickly.
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
[ ... ]
> @@ -3899,11 +3900,25 @@ static int perf_sched__schedstat_record(struct perf_sched *sched,
> if (err < 0)
> goto out;
>
> + /*
> + * Block all handled signals so that a short-lived workload exiting
> + * (SIGCHLD) or an early Ctrl+C (SIGINT/SIGTERM) during the remaining
> + * setup cannot be delivered before we are ready to wait. sigsuspend()
> + * below will atomically unblock them. This is done after
> + * evlist__prepare_workload() so the forked child does not inherit a
> + * modified signal mask.
> + */
> + sigemptyset(&sig_mask);
> + sigaddset(&sig_mask, SIGCHLD);
> + sigaddset(&sig_mask, SIGINT);
> + sigaddset(&sig_mask, SIGTERM);
> + sigprocmask(SIG_BLOCK, &sig_mask, &oldmask);
Does this leave a race window where early signals like SIGINT can be lost,
causing sigsuspend() to hang indefinitely?
If a signal like SIGINT or SIGTERM is delivered before this sigprocmask()
call, the existing sighandler will consume it without setting any state flag
that gets checked here.
> if (argc)
> evlist__start_workload(evlist);
>
> - /* wait for signal */
> - pause();
> + sigsuspend(&oldmask);
When execution subsequently reaches sigsuspend(), wouldn't it block
indefinitely waiting for an event that was already processed?
To robustly resolve the TOCTOU race without leaking a modified signal mask
to the child, should the signal handler set a volatile sig_atomic_t flag,
and sigsuspend() be called conditionally based on that flag?
> + sigprocmask(SIG_SETMASK, &oldmask, NULL);
>
> if (reset) {
> err = disable_sched_schedstat();
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260409162249.25581-1-swapnil.sapkal@amd.com?part=1
next prev parent reply other threads:[~2026-04-09 16:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 16:22 [PATCH v2 0/3] perf: Fix SIGCHLD vs pause() race with short-lived workloads Swapnil Sapkal
2026-04-09 16:22 ` [PATCH v2 1/3] perf sched stats: Fix SIGCHLD race in schedstat_record() Swapnil Sapkal
2026-04-09 16:51 ` sashiko-bot [this message]
2026-04-09 16:22 ` [PATCH v2 2/3] perf sched stats: Fix SIGCHLD race in schedstat_live() Swapnil Sapkal
2026-04-09 17:18 ` sashiko-bot
2026-04-09 16:22 ` [PATCH v2 3/3] perf lock contention: Fix SIGCHLD race in __cmd_contention() Swapnil Sapkal
2026-04-09 17:37 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260409165102.E8A44C4CEF7@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=sashiko@lists.linux.dev \
--cc=swapnil.sapkal@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox