mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Salman Qazi <sqazi@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	taviso@google.com, Roland Dreier <rolandd@cisco.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: Race in ptrace.
Date: Thu, 11 Feb 2010 12:55:58 -0800 (PST)	[thread overview]
Message-ID: <20100211205558.B5BCB8163@magilla.sf.frob.com> (raw)
In-Reply-To: Salman Qazi's message of  Thursday, 11 February 2010 12:39:09 -0800 <4352991a1002111239m681107f8g9e3802daf7ab706b@mail.gmail.com>

> What I don't agree with is that when we send SIGCONT later with
> "kill", we wake up the child at all.  It may make sense to someone who
> has access to the kernel source code, but from a user's point of view
> this is a surprise.  The signal is intercepted and should not have an
> effect on the child.

This is the behavior of SIGCONT and doesn't really have anything to do with
ptrace.  Once you have let the SIGSTOP through, the process is in job
control stop just like if you'd sent a SIGSTOP without using ptrace at all.

The distinction that is confusing you is that *generating* SIGCONT is what
resumes the process, not *delivering* it.  Another example is that if your
process has SIGCONT blocked or ignored, SIGCONT still wakes it up.  Another
example is that SIGCONT wakes up all the threads in a process, before one
of those threads delivers the SIGCONT (i.e. runs a handler).


Thanks,
Roland

  reply	other threads:[~2010-02-11 20:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-08 22:16 Salman Qazi
     [not found] ` <20100208143231.6d804590.akpm@linux-foundation.org>
2010-02-09 11:27   ` Oleg Nesterov
2010-02-10 13:35     ` Oleg Nesterov
2010-02-10 18:38       ` Salman Qazi
2010-02-11 12:56         ` Oleg Nesterov
2010-02-11 16:32           ` Salman Qazi
2010-02-11 16:50             ` Oleg Nesterov
2010-02-11 18:43               ` Salman Qazi
2010-02-11 18:55                 ` Oleg Nesterov
2010-02-11 19:08                   ` Salman Qazi
2010-02-11 20:10                     ` Oleg Nesterov
2010-02-11 20:39                       ` Salman Qazi
2010-02-11 20:55                         ` Roland McGrath [this message]
2010-02-11 21:05                           ` Salman Qazi
2010-02-11 20:59                         ` Oleg Nesterov
  -- strict thread matches above, loose matches on Subject: below --
2010-02-08 22:04 Salman Qazi

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=20100211205558.B5BCB8163@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rolandd@cisco.com \
    --cc=sqazi@google.com \
    --cc=taviso@google.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

all inboxes | Powered by JetHome®