On 03/20, Pavel Labath wrote:
>
> One difference I see though is that in
> our test, we are not sending any additional signals to the thread in
> question (at least we shouldn't be sending them, but we are sending some
> signals to other threads in the same process). Do you think it could still
> be the same issue?
Not sure...
And. I found another race, which looks more promising wrt your description.
ptrace_resume() sets ->exit_code before it wakes the tracee up. If the
tracer's sub-thread calls wait() right after that, it can wrongly see
task_stopped_code(tracee, true) != 0, as if the tracee reports its
->exit_code.
> I would be happy to test your patch. I don't think I can patch the kernel
> on my work machine directly, but I think I might be able to set up some
> sort of a test environment to try it out.
Thanks! could you try the patch below? It won't help my test-case, but
_perhaps_ it can fix the problem you hit?
And a couple of questions just in case...
Which kernel version? Although probably this doesn't matter, this race
is very-very old.
Let me return to your description,
1) we get a waitpid() notification that the tracee got SIGUSR1
2) we do a ptrace(GETSIGINFO) to get more info
3) eventually we decide to restart the tracee with PTRACE_CONT, passing
it
SIGUSR1
4) immediately after that we get another waitpid notification, again
with
SIGUSR1,
Does this "waitpid notification" mean that _another_ thread returns
from waitpid() ?
And status == (SIGUSR1 << 8) | 0x7f , yes? IOW, is WIFSTOPPED() true?
Oleg.
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -724,8 +724,10 @@ static int ptrace_resume(struct task_struct *child, long
request,
user_disable_single_step(child);
}
+ spin_lock_irq(&child->sighand->siglock);
child->exit_code = data;
wake_up_state(child, __TASK_TRACED);
+ spin_unlock_irq(&child->sighand->siglock);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
