From: Daniel Jacobowitz <dan@debian.org>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Proposed manpage additions for ptrace(2)
Date: Fri, 17 Mar 2006 15:04:31 -0500 [thread overview]
Message-ID: <20060317200431.GA20273@nevyn.them.org> (raw)
In-Reply-To: <200603170647_MC3-1-BAD9-ED70@compuserve.com>
On Fri, Mar 17, 2006 at 06:44:21AM -0500, Chuck Ebbert wrote:
> > Specifically, the three kinds of cloning are distinguished as:
> >
> > if CLONE_VFORK -> PTRACE_EVENT_VFORK
> > else if clone exit signal == SIGCHLD -> PTRACE_EVENT_FORK
> > else PTRACE_EVENT_CLONE
> >
> > You need to do some juggling to get the actual clone flags.
>
> It might be best to leave these descriptions in terms of C library functions
> rather than kernel-internal. Looking at sys_clone() and sys_fork() I can see
> what you mean but I'm not sure how to describe it to a programmer.
Those are user accessible flags. Fork will give you a
PTRACE_EVENT_FORK, vfork will give you a PTRACE_EVENT_VFORK, but
clone may give you any of the above, depending on what arguments you
pass to it. The SIGCHLD test matches the bit described in clone(2)
for __WALL or __WCLONE, for instance.
> > BTW, I believe there are still some potential deadlocks between
> > the vfork event and the vfork done event; I used to regularly generate
> > unkillable processes working on this code.
>
> I have a test program and didn't hit any problems yet. Maybe this was fixed?
One thing that IIRC was a problem was killing the parent before the
child (or maybe the other way round) when stopped at this point - such
as would happen if you typed "kill" at a GDB prompt after catch vfork.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-03-17 20:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-17 11:44 [RFC] Proposed manpage additions for ptrace(2) Chuck Ebbert
2006-03-17 20:04 ` Daniel Jacobowitz [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-03-15 9:12 Chuck Ebbert
2006-03-15 20:39 ` Michael Kerrisk
2006-03-16 20:02 ` Daniel Jacobowitz
2006-03-16 21:16 ` Charles P. Wright
2006-03-17 18:46 ` Blaisorblade
2006-03-18 20:37 ` Charles P. Wright
2006-03-25 0:07 ` Blaisorblade
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=20060317200431.GA20273@nevyn.them.org \
--to=dan@debian.org \
--cc=76306.1226@compuserve.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk-manpages@gmx.net \
/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.