svn commit: r269656 - in head: bin/ps sys/kern sys/sys

[Konstantin Belousov]

On Thu, Aug 07, 2014 at 09:48:18AM -0700, Don Lewis wrote:
> On  7 Aug, Konstantin Belousov wrote:
> > Author: kib
> > Date: Thu Aug  7 05:47:53 2014
> > New Revision: 269656
> > URL: http://svnweb.freebsd.org/changeset/base/269656
> > 
> > Log:
> >   Correct the problems with the ptrace(2) making the debuggee an orphan.
> >   One problem is inferior(9) looping due to the process tree becoming a
> >   graph instead of tree if the parent is traced by child. Another issue
> >   is due to the use of p_oppid to restore the original parent/child
> >   relationship, because real parent could already exited and its pid
> >   reused (noted by mjg).
> >   
> >   Add the function proc_realparent(9), which calculates the parent for
> >   given process. It uses the flag P_TREE_FIRST_ORPHAN to detect the head
> >   element of the p_orphan list and than stepping back to its container
> >   to find the parent process. If the parent has already exited, the
> >   init(8) is returned.
> >   
> >   Move the P_ORPHAN and the new helper flag from the p_flag* to new
> >   p_treeflag field of struct proc, which is protected by proctree lock
> >   instead of proc lock, since the orphans relationship is managed under
> >   the proctree_lock already.
> >   
> >   The remaining uses of p_oppid in ptrace(PT_DETACH) and process
> >   reapping are replaced by proc_realparent(9).
> 
> Changing the parent process has always seemed like a hack to me.  It
> seems like the debugger should register itself as an additional parent.
And after that, the pass over the signal delivery and child handling
code must be made to convert all of it to use that new parent, if
available. The good consequence of using the orphans list is that no
wholesale convertion is needed.  Also, looking at the amount of code to
handle and use orphan vs. amount of code which works with p_pptr, it is
obvious which approach is less intrusive into the delicate code, where
all corner cases are features.

In other words, if somebody can provide the patch which 'transposes' the
current approach it would be interesting to see, but I know from the
first-hand experience that the work is large, very hard since all
details must be done right at the first pass, and it would only change
already correct code into something else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20140808/a8bfac9a/attachment.sig>