On 07/20, Peter Zijlstra wrote: > > Also, is there any way to not have ptrace do this?
Well, we need to ensure that even SIGKILL can't wake the tracee up while debugger plays with its registers/etc. > How performance > critical is this ptrace path? This is a slow path. We can probably change ptrace_check_attach() to call ptrace_freeze_traced() after wait_task_inactive(), but I would like to not do this... Because we actually want to avoid wait_task_inactive() when possible. Perhaps ptrace_freeze_traced() can __task_rq_lock() to avoid the race with __schedule() ? No, it reads prev_state before rq_lock(). > Because I really hate having to add code > to __schedule() to deal with this horrible thing. Oh yes, I agree. I have to admit, I do not understand the usage of prev_state in schedule(), it looks really, really subtle... Oleg.
