From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 19:27:34 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 82B07106566C for ; Mon, 30 Jan 2012 19:27:34 +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 15A238FC0A for ; Mon, 30 Jan 2012 19:27:33 +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 q0UJRSlk050688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jan 2012 21:27:28 +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 q0UJRRkN097983; Mon, 30 Jan 2012 21:27: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 q0UJRR9V097982; Mon, 30 Jan 2012 21:27:27 +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: Mon, 30 Jan 2012 21:27:27 +0200 From: Kostik Belousov To: Dmitry Mikulin Message-ID: <20120130192727.GZ2726@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> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0hyMCxJS7FIePeVX" Content-Disposition: inline In-Reply-To: <4F26E0D1.8040100@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: Mon, 30 Jan 2012 19:27:34 -0000 --0hyMCxJS7FIePeVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 30, 2012 at 10:26:25AM -0800, Dmitry Mikulin wrote: >=20 >=20 > On 01/28/2012 11:48 PM, Kostik Belousov wrote: > >On Fri, Jan 27, 2012 at 10:12:13AM -0800, Dmitry Mikulin wrote: > >>Attached are 4 separate patches for each somewhat independent portion = of > >>the kernel work related to the follow-fork implementation. > >Ok, as I said, I think that vfork-fork.patch is just wrong. >=20 > Gdb needs to be able to read/write process memory between the time the=20 > child is forked and exec is called (in the vfork case). Without the chang= e=20 > it causes a kernel panic when gdb tries to read/write process memory. Sin= ce=20 > my understanding of the kernel is a bit limited, it was the best I could = do=20 > at the time. I will send more details about the panic once I get a workin= g=20 > fbsd system again. Maybe there's a better way to deal with the panic. Please provide more details, I am looking forward for the panic message and backtrace. >=20 > >Lets postpone discussion of the orphan.patch for later. >=20 > OK. >=20 > > > >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). >=20 >=20 >=20 >=20 > > > >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. >=20 > I think this will fix only a part of the problem, the one that relates to= =20 > PT_CONTINUE. >=20 > I still need the change that forces a stop in both child and parent on=20 > fork(). Without my changes the notification is generated in the child but= =20 > not in the parent. I need to be able to have both processes stopped in gd= b=20 > in order to clean up and detach from the parent, and initialize and attac= h=20 > to the child. The main reason I need both processes stopped is that gdb h= as=20 > to be able to read/write into both processes address space and registers.= =20 > Ideally I would like to have a single event generated for fork() at a poi= nt=20 > where both child and parent are stopped and available for ptrace read/wri= te=20 > requests. Do you think it's possible? The lack of the notification for parent is exactly what the patch I posted fixes. More exactly, it is the lack of notification for parent with PT_CONTINUE loop. I will commit this today. Regarding a single notification. Currently, parent arrives at the syscall return code only after the child is attached to the debugger. See the cv_wait() in kern_fork.c:739. In other words, if you get the PL_FLAG_FORK, the child is already attached (at last it shall be). My scescx.c code illustrates this well, IMO. You still get a separate stop from the child, but I do not see how is it harmful. --0hyMCxJS7FIePeVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8m7x8ACgkQC3+MBN1Mb4ivfQCg5u5En+NVmD/0ZzPNUvv2AvXX C2QAoKM1fcZjqnvhOoXCYrL7wFWPlqDS =MLgx -----END PGP SIGNATURE----- --0hyMCxJS7FIePeVX--