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]>
--- 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,
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
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.
> 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
On Tue, 20 Nov 2007 13:28:51 -0800 (PST)
Roland McGrath <[email protected]> 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.
On 11/20, Andrew Morton wrote:
>
> On Tue, 20 Nov 2007 13:28:51 -0800 (PST)
> Roland McGrath <[email protected]> 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.