This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ptrace improvement: PTRACE_O_INHERIT


On 02/15, Jan Kratochvil wrote:
>
> On Tue, 15 Feb 2011 14:08:05 +0100, Oleg Nesterov wrote:
>
> > Suppose that debugger uses PTRACE_O_INHERIT and then it decides to detach
> > gracefully. It should detach per-thread, but how? /proc is very unconvenient.
> > Even if we traced all threads, we do not trace them all after we detach
> > the first thread, and that thread can clone the new threads after detach.
>
> Maybe it is obvious but it has not been heard yet.
> With PTRACE_O_THREAD_INHERIT the debugger no longer has to enumerate threads
> for ptrace operations - except for attach+detach.
>
> Could PTRACE_ATTACH_NOSTOP+PTRACE_DETACH_NOSTOP? act on the whole PID at once
> if PTRACE_O_THREAD_INHERIT is applied - already during PTRACE_ATTACH_NOSTOP?
> It is a bit overloading the *_NOSTOP meaning but it is a new PTRACE_* op.

Yes, I thought about PTRACE_ATTACH_TG / PTRACE_DETACH_TG too.

This is nontrivial to implement. We should obviously avoid the races with
clone(). Now that cred_guard_mutex is per-process, this is probably possible...
But I can't understand how we can check __ptrace_may_access() for each thread.
We should refactor this code, task_lock() is needed to pin ->mm, and ->mm
should be the same. Anyway, looks possible.

Oleg.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]