From owner-freebsd-current@FreeBSD.ORG Sun Jan 29 07:50:52 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 88776106564A for ; Sun, 29 Jan 2012 07:50:52 +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 1A4DD8FC08 for ; Sun, 29 Jan 2012 07:50:51 +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 q0T7mie3002942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jan 2012 09:48:44 +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 q0T7mhcM085676; Sun, 29 Jan 2012 09:48:43 +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 q0T7mhNl085675; Sun, 29 Jan 2012 09:48:43 +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: Sun, 29 Jan 2012 09:48:43 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120129074843.GL2726@deviant.kiev.zoral.com.ua> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiQKDdln2jY//0TJ" Content-Disposition: inline In-Reply-To: <4F22E8FD.6010201@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: Sun, 29 Jan 2012 07:50:52 -0000 --YiQKDdln2jY//0TJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote: > Attached are 4 separate patches for each somewhat independent portion of= =20 > the kernel work related to the follow-fork implementation. Ok, as I said, I think that vfork-fork.patch is just wrong. Lets postpone discussion of the orphan.patch for later. The follow-fork.patch and follow-exec.patch make me wonder, and I already expressed my doubts. IMO, all features, except one bug, are already presented in the stock src. More, suggested follow-{fork,exec} patches break the SCE/SCX tracers notification of fork and exec events, since TDB_FORK and TBD_EXEC flags are consumed before syscall returns (I also said this previously). Namely, if the process is being debugged, the successfull [f]execve() causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not revealed by my testing during the development, because I only tested SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next stop is not SCX, then follow-fork notification is not sent. After this nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. Child is put into stop state as needed to not loose it. I updated the test program I use to test this functionality, see http://people.freebsd.org/~kib/misc/scescx.c The default or -s flag causes it to use SCE/SCX tracing, while -c flag switches it to use PT_CONTINUE tracing, which should be the kind of loop performed by normal debuggers. You can see the exec/fork events and child auto-attach illustrated with this test. Can you, please, provide the test-case which illustrates the omissions in the existing API (with the patch below applied), if any ? diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c index bba4479..75328f6 100644 --- a/sys/kern/subr_syscall.c +++ b/sys/kern/subr_syscall.c @@ -212,7 +212,8 @@ syscallret(struct thread *td, int error, struct syscall= _args *sa __unused) * executes. If debugger requested tracing of syscall * returns, do it now too. */ - if (traced && ((td->td_dbgflags & TDB_EXEC) !=3D 0 || + if (traced && + ((td->td_dbgflags & (TDB_FORK | TDB_EXEC)) !=3D 0 || (p->p_stops & S_PT_SCX) !=3D 0)) ptracestop(td, SIGTRAP); td->td_dbgflags &=3D ~(TDB_SCX | TDB_EXEC | TDB_FORK); --YiQKDdln2jY//0TJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8k+dsACgkQC3+MBN1Mb4iRwQCeJKKjGvUpb9zx7gCfTJlB6nHX +PAAnjnEqI1R//4d60AZqhopRRNUBlkP =VY94 -----END PGP SIGNATURE----- --YiQKDdln2jY//0TJ--