From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 07:48:32 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 2DB36106566C for ; Wed, 25 Jan 2012 07:48:32 +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 956CE8FC13 for ; Wed, 25 Jan 2012 07:48:31 +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 q0P7mOVB006610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 09:48:24 +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 q0P7mO8l009272; Wed, 25 Jan 2012 09:48:24 +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 q0P7mO16009271; Wed, 25 Jan 2012 09:48:24 +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: Wed, 25 Jan 2012 09:48:24 +0200 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20120125074824.GD2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline In-Reply-To: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@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 , Dmitry Mikulin 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: Wed, 25 Jan 2012 07:48:32 -0000 --OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2012 at 01:36:55PM -0800, Marcel Moolenaar wrote: > All, >=20 > Please review the attached changes (done by Dmitry -- CC'd) to add suppor= t for > PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK. >=20 > I'll commit this when there are no comments/objections. > Thanks, 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 ? 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. If possible, I would greatly prefer to have fork changes separated. 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. Why do we need to have TDB_FORK set for td2 ? 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. --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8fs8gACgkQC3+MBN1Mb4iV5wCgzqH0Lf3OWLNVKFnebVoXiLqn 1dMAnjkLw03Q6x/DarX4KxiaXBTyiefI =0ixd -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc--