[PATCH -mm 1/2] kill PT_PTRACED

[PATCH -mm 1/2] kill PT_PTRACED

[Oleg Nesterov]

Since the patch

	"Fix ptrace_attach()/ptrace_traceme()/de_thread() race"
	commit f5b40e363ad6041a96e3da32281d8faa191597b9

we set PT_ATTACHED and change child->parent "atomically" wrt task_list lock.

This means we can remove the checks like "PT_ATTACHED && ->parent != ptracer"
which were needed to catch the "ptrace attach is in progress" case. We can also
remove the flag itself since nobody else uses it.

Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>

--- PT/include/linux/ptrace.h~1_PT_ATTACHED	2007-07-28 16:58:17.000000000 +0400
+++ PT/include/linux/ptrace.h	2007-11-20 17:22:13.000000000 +0300
@@ -67,7 +67,6 @@
 #define PT_TRACE_EXEC	0x00000080
 #define PT_TRACE_VFORK_DONE	0x00000100
 #define PT_TRACE_EXIT	0x00000200
-#define PT_ATTACHED	0x00000400	/* parent != real_parent */
 
 #define PT_TRACE_MASK	0x000003f4
 
--- PT/kernel/ptrace.c~1_PT_ATTACHED	2007-11-20 17:16:10.000000000 +0300
+++ PT/kernel/ptrace.c	2007-11-20 17:26:05.000000000 +0300
@@ -100,8 +100,7 @@ int ptrace_check_attach(struct task_stru
 	 */
 	read_lock(&tasklist_lock);
 	if ((child->ptrace & PT_PTRACED) && child->parent == current &&
-	    (!(child->ptrace & PT_ATTACHED) || child->real_parent != current)
-	    && child->signal != NULL) {
+	     child->sighand != NULL) {
 		ret = 0;
 		spin_lock_irq(&child->sighand->siglock);
 		if (is_task_stopped(child)) {
@@ -202,8 +201,7 @@ repeat:
 		goto bad;
 
 	/* Go */
-	task->ptrace |= PT_PTRACED | ((task->real_parent != current)
-				      ? PT_ATTACHED : 0);
+	task->ptrace |= PT_PTRACED;
 	if (capable(CAP_SYS_PTRACE))
 		task->ptrace |= PT_PTRACE_CAP;
 
--- PT/kernel/signal.c~1_PT_ATTACHED	2007-11-20 17:16:10.000000000 +0300
+++ PT/kernel/signal.c	2007-11-20 17:27:28.000000000 +0300
@@ -1577,11 +1577,6 @@ static inline int may_ptrace_stop(void)
 {
 	if (!likely(current->ptrace & PT_PTRACED))
 		return 0;
-
-	if (unlikely(current->parent == current->real_parent &&
-		    (current->ptrace & PT_ATTACHED)))
-		return 0;
-
 	/*
 	 * Are we in the middle of do_coredump?
 	 * If so and our tracer is also part of the coredump stopping
--- PT/kernel/exit.c~1_PT_ATTACHED	2007-11-20 17:16:10.000000000 +0300
+++ PT/kernel/exit.c	2007-11-20 17:21:52.000000000 +0300
@@ -1513,18 +1513,7 @@ static int wait_task_continued(struct ta
 
 static inline int my_ptrace_child(struct task_struct *p)
 {
-	if (!(p->ptrace & PT_PTRACED))
-		return 0;
-	if (!(p->ptrace & PT_ATTACHED))
-		return 1;
-	/*
-	 * This child was PTRACE_ATTACH'd.  We should be seeing it only if
-	 * we are the attacher.  If we are the real parent, this is a race
-	 * inside ptrace_attach.  It is waiting for the tasklist_lock,
-	 * which we have to switch the parent links, but has already set
-	 * the flags in p->ptrace.
-	 */
-	return (p->parent != p->real_parent);
+	return p->ptrace & PT_PTRACED;
 }
 
 static long do_wait(pid_t pid, int options, struct siginfo __user *infop,

Re: [PATCH -mm 1/2] kill PT_PTRACED

[Roland McGrath]

Subject should be "kill PT_ATTACHED".

> -	    (!(child->ptrace & PT_ATTACHED) || child->real_parent != current)
> -	    && child->signal != NULL) {
> +	     child->sighand != NULL) {

This does s/signal/sighand/ without comment.

Otherwise the main thrust of the patch seems fine to me.


Thanks,
Roland

Re: [PATCH -mm 1/2] kill PT_PTRACED

[Oleg Nesterov]

On 11/20, Roland McGrath wrote:
>
> Subject should be "kill PT_ATTACHED".
> 
> > -	    (!(child->ptrace & PT_ATTACHED) || child->real_parent != current)
> > -	    && child->signal != NULL) {
> > +	     child->sighand != NULL) {
> 
> This does s/signal/sighand/ without comment.

Ah yes, sorry, forgot to add the comment.

This is microoptimization, both ->signal and ->sighand are cleared at the same
time in __exit_signal(), so we can check either. But we are using the value of
->sighand below, so it makes sense to read ->sighand, not ->signal.

Andrew, it is very easy to send the new patch to fix the code, but is it possible
to fix the changelog somehow for the patch in -mm tree?

Oleg.

Re: [PATCH -mm 1/2] kill PT_PTRACED

[Roland McGrath]

> This is microoptimization, both ->signal and ->sighand are cleared at the same
> time in __exit_signal(), so we can check either. But we are using the value of
> ->sighand below, so it makes sense to read ->sighand, not ->signal.

Ok.  Anality would suggest doing that in a separate patch, though I don't
really care.

> Andrew, it is very easy to send the new patch to fix the code, but is it
> possible to fix the changelog somehow for the patch in -mm tree?

I'd prefer a comment in the code there making it explicit that ->sighand is
a "reaped yet" synchronization check (under tasklist_lock).


Thanks,
Roland

Re: [PATCH -mm 1/2] kill PT_PTRACED

[Andrew Morton]

On Tue, 20 Nov 2007 13:28:51 -0800 (PST)
Roland McGrath <roland@redhat.com> wrote:

> > Andrew, it is very easy to send the new patch to fix the code, but is it
> > possible to fix the changelog somehow for the patch in -mm tree?

Sure, just send me the new text.

> I'd prefer a comment in the code there making it explicit that ->sighand is
> a "reaped yet" synchronization check (under tasklist_lock).

that works too.

Re: [PATCH -mm 1/2] kill PT_PTRACED

[Oleg Nesterov]

On 11/20, Andrew Morton wrote:
>
> On Tue, 20 Nov 2007 13:28:51 -0800 (PST)
> Roland McGrath <roland@redhat.com> wrote:
> 
> > > Andrew, it is very easy to send the new patch to fix the code, but is it
> > > possible to fix the changelog somehow for the patch in -mm tree?
> 
> Sure, just send me the new text.
> 
> > I'd prefer a comment in the code there making it explicit that ->sighand is
> > a "reaped yet" synchronization check (under tasklist_lock).
> 
> that works too.

Will do tomorrow. Actually, I just realized we don't need need either check.
release_task() first does ptrace_unlink(), then __exit_signal(). This means
that (child->ptrace & PT_PTRACED) under tasklist_lock implies we have the valid
->sighand/signal.

Will send the patch with the comment.

Oleg.