From owner-freebsd-current@FreeBSD.ORG Thu Jan 26 12:23:35 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606B7106564A for ; Thu, 26 Jan 2012 12:23:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E841F8FC12 for ; Thu, 26 Jan 2012 12:23:34 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0QCNRGo065184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jan 2012 14:23:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0QCNRLT035256; Thu, 26 Jan 2012 14:23:27 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0QCNQUv035255; Thu, 26 Jan 2012 14:23:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 26 Jan 2012 14:23:26 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120126122326.GT2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r3KnbM2MoJFBL7Dl" Content-Disposition: inline In-Reply-To: <4F2094B4.70707@juniper.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:23:35 -0000 --r3KnbM2MoJFBL7Dl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 03:48:04PM -0800, Dmitry Mikulin wrote: > Thanks for taking a look at it. I'll try to explain the changes the best = I=20 > can: the work was done nearly 6 months ago... >=20 > >I would certainly appreciate some more words describing the changes. > > > >What is the goal of introducing the PT_FOLLOW_EXEC ? To not force > >the debugger to filter all syscall exits to see exec events ? >=20 > PT_FOLLOW_EXEC was added to trace the exec() family of calls. When it's= =20 > enabled, the kernel will generate a trap to give debugger a chance to cle= an=20 > up old process info and initialize its state with the new binary. >=20 It was more a question, why PT_FLAG_EXEC is not enough. >=20 >=20 > > > >Why did you moved the stopevent/ptracestop for exec events from > >syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC > >is not removed from syscallret() ? I do not think that TDB_EXEC can be > >seen there after the patch. The same question about TDB_FORK. >=20 > The reason I moved the event notifications from syscallret() is because t= he=20 > debugger is interested successful completion of either fork or exec, not= =20 > just the fact that they have been called. If, say, a call to fork() faile= d,=20 > as far as debugger is concerned, fork() might as well had never been=20 > called. Having a ptracestop in syscallret triggered a trap on every retur= n=20 > from fork without telling the debugger whether a new process had been=20 > created or not. Same goes for exec(). PT_FLAG_EXEC is only set if an exec-kind of syscall succeeded. The same is true for PT_FLAG_FORKED, the flag is set only if a new child was successfully created. >=20 > Looking at the code now I think I should have removed TDB_EXEC/TDB_FORK= =20 > processing from syscallret(). I'll do that and verify that it works as=20 > expected. >=20 > > > >If possible, I would greatly prefer to have fork changes separated. >=20 > You mean separate fork changes into a separate patch from exec changes? Yes. Even more, it seems that fork changes should be separated into bug fixes and new functionality. >=20 > > > >I doubt that disallowing RFMEM while tracing is the right change. It may > >be to fix some (undescribed) bug, but RFMEM is documented behaviour used > >not only for vfork(2), and the change just breaks rfork(2) for debugged > >processes. > > > >Even vfork() should not be broken, since I believe there are programs > >that rely on the vfork() model, in particular, C shell. It will be > >broken if vfork() is substituted by fork(). The fact that it breaks only > >under debugger will make it esp. confusing. >=20 > I need to dig up the details since I can't recall the exact reason for=20 > forcing fork() in cases of user calls to vfork() under gdb. I believe it= =20 > had to do with when child process memory was available for writing in cas= e=20 > of vfork() and it wasn't early enough to complete the switch over from=20 > parent to child in gdb. After consulting with our internal kernel experts= =20 > we decided that doing fork() instead of vfork() under gdb is a low impact= =20 > change. >=20 > > > >Why do we need to have TDB_FORK set for td2 ? >=20 > The debugger needs to intercept fork() in both parent and child so it can= =20 > detach from the old process and attach to the new one. Maybe it'll make= =20 > more sense in the context of gdb changes. Should I send them too? Don't= =20 > think Marcel included that patch... No, I think the kernel changes are enough for now. >=20 > > > >Does the orphan list change intended to not lost the child after fork ? > >But the child shall be traced, so debugger would get the SIGTRAP on > >the attach on fork returning to usermode. I remember that I explicitely > >tested this when adding followfork changes. >=20 > Yes, the debugger gets SIGTRAPs. The problem arises when the real parent = of=20 > the forked process has the code to collect termination status. Since=20 > attaching to a process changes the parent/child relationships, we need to= =20 > keep track of the children lost due to re-parenting so we can properly=20 > attribute their exit status to the "real" parent. >=20 I do not quite understand it. From the description it sounds as the problem that is not related to follow fork changes at all, and shall be presented regardless of the follow fork. If yes, I think this shall be separated into a standalone patch. --r3KnbM2MoJFBL7Dl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8hRb4ACgkQC3+MBN1Mb4jGNQCfULh439QfL2w1Ee6a+YbpEFcf srMAn2cMTjcJJERhtUJMg2waeBllWk3B =BUX5 -----END PGP SIGNATURE----- --r3KnbM2MoJFBL7Dl--