Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 4 Feb 2012 22:42:18 +0200
From:      Konstantin 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:  <20120204204218.GC3283@deviant.kiev.zoral.com.ua>
In-Reply-To: <4F2C756A.80900@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> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> <4F2C756A.80900@juniper.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--JQcTy30AFu/Rhea+
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 03, 2012 at 04:01:46PM -0800, Dmitry Mikulin wrote:
>=20
> >Please provide more details, I am looking forward for the panic
> >message and backtrace.
>=20
> I can't seem to get the panic with the latest source base, but tracing=20
> doesn't appear to work with vfork(). I attached a modified test case to=
=20
> closer model what gdb is doing. If you change fork() to vfork() in simple=
.c=20
> the parent doesn't get the events the same way it does under fork().
I see what is going on. The wait loop for P_PPWAIT in do_fork() simply
do not allow the ptracestop() in the syscall return path to be reached.
There seems to be more problems. In particular, I do not see anything
which would prevent the child from being reapped while the loop is
executing (assume that the parent is multithreaded and other thread
processed SIGCHLD and called wait).

Lets deal with these bugs after your proposal for interface changes is
dealt with.

>=20
> >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.
>=20
> There a couple of tweaks to the interface that I'd like to have:
> - set PL_FLAG_FORKED in the child so gdb can identify the stop as a fork(=
)=20
> event.
> - add a switch similar to PT_FOLLOW_FORK to enable/disable exec()=20
> notifications. Gdb gets confused by the events it hasn't explicitly asked=
=20
> for and having a switch makes it easier to filter out unwanted stops.
>=20
> Do you think it's possible/makes sense?

Yes, I agree with the proposal to add flag to the child lwp info.
I think it will be easier if the flag is different from PL_FLAG_FORKED.
I named it PL_FLAG_CHILD.

PT_FOLLOW_EXEC is easy to implement, but my question is, how can debugger
operate (correctly) if it ignores exec events ? After exec, the whole
cached state of the debuggee must be invalidated, and since debugger
ignores the notification when the invalidation shall be done, it probably
gets very confused.

Anyway, below is the combined patch that adds PL_FLAG_CHILD and
PT_FOLLOW_EXEC. If you agree with this, I will commit them (separately).

diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index 135f798..c756777 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -889,7 +889,8 @@ exec_fail_dealloc:
=20
 	if (error =3D=3D 0) {
 		PROC_LOCK(p);
-		td->td_dbgflags |=3D TDB_EXEC;
+		if ((p->p_flag & P_NOFOLLOWEXEC) =3D=3D 0)
+			td->td_dbgflags |=3D TDB_EXEC;
 		PROC_UNLOCK(p);
=20
 		/*
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index 60639c9..e447c93 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -1035,7 +1035,9 @@ fork_return(struct thread *td, struct trapframe *fram=
e)
 			p->p_oppid =3D p->p_pptr->p_pid;
 			proc_reparent(p, dbg);
 			sx_xunlock(&proctree_lock);
+			td->td_dbgflags |=3D TDB_CHILD;
 			ptracestop(td, SIGSTOP);
+			td->td_dbgflags &=3D ~TDB_CHILD;
 		} else {
 			/*
 			 * ... otherwise clear the request.
diff --git a/sys/kern/sys_process.c b/sys/kern/sys_process.c
index 4510380..f58039a 100644
--- a/sys/kern/sys_process.c
+++ b/sys/kern/sys_process.c
@@ -660,6 +660,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void=
 *addr, int data)
 	case PT_TO_SCX:
 	case PT_SYSCALL:
 	case PT_FOLLOW_FORK:
+	case PT_FOLLOW_EXEC:
 	case PT_DETACH:
 		sx_xlock(&proctree_lock);
 		proctree_locked =3D 1;
@@ -873,6 +874,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid, voi=
d *addr, int data)
 		else
 			p->p_flag &=3D ~P_FOLLOWFORK;
 		break;
+	case PT_FOLLOW_EXEC:
+		if (data)
+			p->p_flag &=3D ~P_NOFOLLOWEXEC;
+		else
+			p->p_flag |=3D P_NOFOLLOWEXEC;
+		break;
=20
 	case PT_STEP:
 	case PT_CONTINUE:
@@ -936,7 +943,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, void=
 *addr, int data)
 					p->p_sigparent =3D SIGCHLD;
 			}
 			p->p_oppid =3D 0;
-			p->p_flag &=3D ~(P_TRACED | P_WAITED | P_FOLLOWFORK);
+			p->p_flag &=3D ~(P_TRACED | P_WAITED | P_FOLLOWFORK |
+			    P_NOFOLLOWEXEC);
=20
 			/* should we send SIGCHLD? */
 			/* childproc_continued(p); */
@@ -1145,6 +1153,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid, vo=
id *addr, int data)
 			pl->pl_flags |=3D PL_FLAG_FORKED;
 			pl->pl_child_pid =3D td2->td_dbg_forked;
 		}
+		if (td2->td_dbgflags & TDB_CHILD)
+			pl->pl_flags |=3D PL_FLAG_CHILD;
 		pl->pl_sigmask =3D td2->td_sigmask;
 		pl->pl_siglist =3D td2->td_siglist;
 		strcpy(pl->pl_tdname, td2->td_name);
diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index 76f3355..91bc86e 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -384,6 +384,7 @@ do {									\
 				      process */
 #define	TDB_STOPATFORK	0x00000080 /* Stop at the return from fork (child
 				      only) */
+#define	TDB_CHILD	0x00000100 /* New child indicator for ptrace() */
=20
 /*
  * "Private" flags kept in td_pflags:
@@ -613,6 +614,7 @@ struct proc {
 #define	P_HWPMC		0x800000 /* Process is using HWPMCs */
=20
 #define	P_JAILED	0x1000000 /* Process is in jail. */
+#define	P_NOFOLLOWEXEC	0x2000000 /* Do not report execs with ptrace. */
 #define	P_INEXEC	0x4000000 /* Process is in execve(). */
 #define	P_STATCHILD	0x8000000 /* Child process stopped or exited. */
 #define	P_INMEM		0x10000000 /* Loaded into memory. */
diff --git a/sys/sys/ptrace.h b/sys/sys/ptrace.h
index 2583d59..05c758c 100644
--- a/sys/sys/ptrace.h
+++ b/sys/sys/ptrace.h
@@ -64,6 +64,7 @@
 #define	PT_SYSCALL	22
=20
 #define	PT_FOLLOW_FORK	23
+#define	PT_FOLLOW_EXEC	24
=20
 #define PT_GETREGS      33	/* get general-purpose registers */
 #define PT_SETREGS      34	/* set general-purpose registers */
@@ -106,7 +107,8 @@ struct ptrace_lwpinfo {
 #define	PL_FLAG_SCX	0x08	/* syscall leave point */
 #define	PL_FLAG_EXEC	0x10	/* exec(2) succeeded */
 #define	PL_FLAG_SI	0x20	/* siginfo is valid */
-#define	PL_FLAG_FORKED	0x40	/* new child */
+#define	PL_FLAG_FORKED	0x40	/* child born */
+#define	PL_FLAG_CHILD	0x80	/* I am from child */
 	sigset_t	pl_sigmask;	/* LWP signal mask */
 	sigset_t	pl_siglist;	/* LWP pending signal */
 	struct __siginfo pl_siginfo;	/* siginfo for signal */

--JQcTy30AFu/Rhea+
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk8tmCkACgkQC3+MBN1Mb4h+UACfafFIz2TEj7aLvUsa9iNFpkL1
KOUAoM7eOMYUntzhYZMqBQVVI/a73dPV
=dYNp
-----END PGP SIGNATURE-----

--JQcTy30AFu/Rhea+--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120204204218.GC3283>