Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Aug 2014 07:21:43 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r269656 - in head: bin/ps sys/kern sys/sys
Message-ID:  <20140808042143.GA93733@kib.kiev.ua>
In-Reply-To: <201408071648.s77GmI98043796@gw.catspoiler.org>
References:  <53e31309.5581.568424c9@svn.freebsd.org> <201408071648.s77GmI98043796@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--O/Q8kNx4kEBIW7e9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
> >=20
> > 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).
> >  =20
> >   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.
> >  =20
> >   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.
> >  =20
> >   The remaining uses of p_oppid in ptrace(PT_DETACH) and process
> >   reapping are replaced by proc_realparent(9).
>=20
> 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.

--O/Q8kNx4kEBIW7e9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJT5FBWAAoJEJDCuSvBvK1B3WsP/2NzSHOo+H59oB1XM9/LIXPj
i90L2MVrXpL0bGz4XEcoYxq9oh7pyCSBgSJjnh/F/i47gE+2CMITd6m4Qy8VuWtG
TGqK0U2QT1xVr1u3S82Dkhi3PZ8QtuAeuwr6+ssOqfZmiCgzjeV3c0aiD9GgHav7
yVBZu85+blUiaQJ5oB088mmV0e5plTfpWuCo90+j+IFxL4diFKkEEu63lqGfSXlf
oEgsoF1L6Fgfam7EPaATkhKmZLWWB15R64YDXbBPqH7yDUaxYEc8IdJsiGo4Dc6M
yVoh3dceXNVv2wN5oQZCZaJOIWAYiiO5GkKJYgdSc8vVYqoyhrShdD3Yl/hgk4E2
dyQp7XLEcaKUZB3wYsIotsLpVEd9W3RDUoQBJgXYcjq8VKJfhQzGaEO1cX9QhyBP
Wy2OVG3IpwvhZtRwxuttBoP+Et479qLXzd3LxvZZieLtWtXkxcyhLjW/M2Ya+oCs
QgIURco/ZzT3qlvHAfb/fy5+C/8dRzFpa2m1yE4dxl117ImpB5VcwCFZzcCQ9DnB
PbMg/F7IDh31LMa+39w87TlmpDDLHYfmDQTlxEA95rgQkXxDT1ByDWOwSx4cquEA
+GwaCgOAfBiznEp8usxGJPWJ56JNeetnscAMkNXJWEMmT8i5RqLkH5UzwaKksmlk
vyGosN0ibaWoJZKTupZE
=lVSN
-----END PGP SIGNATURE-----

--O/Q8kNx4kEBIW7e9--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140808042143.GA93733>