Skip to contentSkip to conversation

kill PT_PTRACED

PATCH In review Oleg Nesterov 3 participants 6 messages Nov 20, 2007 ptrace support

lore
Share & tools
lore

Oleg Nesterov

author
#0 lore raw

PATCH 1/2 kill PT_PTRACED

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 <[email protected]>
include/linux/ptrace.h renamed from include/linux/ptrace.h~1_PT_ATTACHED +0 -1
@@ -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
kernel/ptrace.c renamed from kernel/ptrace.c~1_PT_ATTACHED +2 -4
@@ -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;
kernel/signal.c renamed from kernel/signal.c~1_PT_ATTACHED +0 -5
@@ -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
kernel/exit.c renamed from kernel/exit.c~1_PT_ATTACHED +1 -12
@@ -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,
#1 lore raw

Subject should be "kill PT_ATTACHED".

kernel/ptrace.c int ptrace_check_attach(struct task_stru · line 103

Quoted 3 lines
kernel/ptrace.c renamed from kernel/ptrace.c~1_PT_ATTACHED +1 -2
-	    (!(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

author
#2 lore raw
Quoted 8 lines · Roland McGrath

Subject should be "kill PT_ATTACHED".

kernel/ptrace.c int ptrace_check_attach(struct task_stru · line 103

Quoted 3 lines
kernel/ptrace.c renamed from kernel/ptrace.c~1_PT_ATTACHED +1 -2
-	    (!(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.

#3 lore raw
Quoted 3 lines

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.

Quoted 2 lines

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

#4 lore raw
Quoted 2 lines · On Tue, 20 Nov 2007 13:28:51 -0800 (PST) Roland McGrath <[email protected]>…
Quoted 2 lines

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.

Quoted 2 lines

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.

author
#5 lore raw
Quoted 7 lines · Andrew Morton
Quoted 2 lines · On Tue, 20 Nov 2007 13:28:51 -0800 (PST) Roland McGrath <[email protected]>…
Quoted 2 lines

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?

Quoted 6 lines

Sure, just send me the new text.

Quoted 2 lines

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.