All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Munsie <imunsie@au1.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf: prevent kill(0, SIGTERM);
Date: Tue, 15 Jun 2010 12:34:40 +1000	[thread overview]
Message-ID: <1276568830-sup-3577@au1.ibm.com> (raw)
In-Reply-To: <1276072680-17378-1-git-send-email-imunsie@au1.ibm.com>

Hi Ingo,

Please consider merging this patch, it's a trivial fix to prevent perf
from killing too many processes in certain unusual situations - such as
killing the other intern's entire X session when called from eclipse
with a typo in the program being profiled.

Cheers,
-Ian

Excerpts from Ian Munsie's message of Wed Jun 09 18:38:00 +1000 2010:
> From: Ian Munsie <imunsie@au1.ibm.com>
> 
> At exit, perf record will kill the process it was profiling by sending a
> SIGTERM to child_pid (if it had been initialised), but in certain
> situations child_pid may be 0 and perf would mistakenly kill more
> processes than intended.
> 
> child_pid is set to the return of fork() to either 0 or the pid of the
> child. Ordinarily this would not present an issue as the child calls
> execvp to spawn the process to be profilled and would therefore never
> run it's sig_atexit and never attempt to kill pid 0.
> 
> However, if a nonexistant binary had been passed in to perf record the
> call to execvp would fail and child_pid would be left set to 0. The
> child would then exit and it's atexit handler, finding that child_pid
> was initialised to 0, would call kill(0, SIGTERM), resulting in every
> process within it's process group being killed.
> 
> In the case that perf was being run directly from the shell this
> typically would not be an issue as the shell isolates the process.
> However, if perf was being called from another program it could kill
> unexpected processes, which may even include X.
> 
> This patch changes the logic of the test for whether child_pid was
> initialised to only considder positive pids as valid, thereby never
> attempting to kill pid 0.
> 
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> ---
>  tools/perf/builtin-record.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 5e5c640..300da82 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -193,7 +193,7 @@ static void sig_handler(int sig)
>  
>  static void sig_atexit(void)
>  {
> -    if (child_pid != -1)
> +    if (child_pid > 0)
>          kill(child_pid, SIGTERM);
>  
>      if (signr == -1)

  reply	other threads:[~2010-06-15  2:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09  8:38 [PATCH] perf: prevent kill(0, SIGTERM); Ian Munsie
2010-06-15  2:34 ` Ian Munsie [this message]
2010-06-17 20:20 ` Arnaldo Carvalho de Melo

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=1276568830-sup-3577@au1.ibm.com \
    --to=imunsie@au1.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.