Date: Sun, 29 Jan 2012 09:48:43 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Dmitry Mikulin <dmitrym@juniper.net> Cc: freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcelm@juniper.net> Subject: Re: [ptrace] please review follow fork/exec changes Message-ID: <20120129074843.GL2726@deviant.kiev.zoral.com.ua> In-Reply-To: <4F22E8FD.6010201@juniper.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120129074843.GL2726>