[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1291654624-6230-17-git-send-email-tj@kernel.org>
Date: Mon, 6 Dec 2010 17:57:04 +0100
From: Tejun Heo <tj@...nel.org>
To: oleg@...hat.com, roland@...hat.com, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
rjw@...k.pl, jan.kratochvil@...hat.com
Cc: Tejun Heo <tj@...nel.org>
Subject: [PATCH 16/16] ptrace: remove the extra wake_up_process() from ptrace_detach()
This wake_up_process() has a turbulent history. This is a remnant
from ancient ptrace implementation and patently wrong. Commit
95a3540d (ptrace_detach: the wrong wakeup breaks the ERESTARTxxx
logic) removed it but the change was reverted later by commit edaba2c5
(ptrace: revert "ptrace_detach: the wrong wakeup breaks the
ERESTARTxxx logic ") citing compatibility breakage and general
brokeness of the whole group stop / ptrace interaction.
Digging through the mailing archives, the compatibility breakage
doesn't seem to be critical in the sense that the behavior isn't well
defined or reliable to begin with and it seems to have been agreed to
remove the wakeup with proper cleanup of the whole thing.
Now that the group stop and its interaction with ptrace are cleaned up
and well defined, it's high time to finally kill this silliness.
Signed-off-by: Tejun Heo <tj@...nel.org>
Cc: Oleg Nesterov <oleg@...hat.com>
Cc: Roland McGrath <roland@...hat.com>
---
kernel/ptrace.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index dba6aeb..575bf8f 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -391,8 +391,6 @@ int ptrace_detach(struct task_struct *child, unsigned int data)
if (child->ptrace) {
child->exit_code = data;
dead = __ptrace_detach(current, child);
- if (!child->exit_state)
- wake_up_process(child);
}
write_unlock_irq(&tasklist_lock);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists