Messages in this thread | | | Date | Wed, 25 May 2011 20:29:19 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE |
| |
On 05/24, Tejun Heo wrote: > > Hello, Oleg. > > On Mon, May 23, 2011 at 02:43:14PM +0200, Oleg Nesterov wrote: > > On 05/18, Tejun Heo wrote: > > > I've been thinking about Jan's suggestion to make ATTACH and DETACH > > > not require tracee to trap. We already have this for DETACH for cases > > > where the tracer is killed > > > > Yes, I still think that the new DETACH_XXX request which doesn't need > > the stopped tracee makes sense. Yes, we have PTRACE_INTERRUPT. But please > > recall the previous discussion, it is possible that the tracee can't > > react to PTRACE_INTERRUPT and trap because it waits for other threads > > we are tracing. > > Yeah, untrapped DETACH sounds nice but as you've already acknowledged > in another reply, we have those nasty disable traps.
Yes. Which I never thought about, I alway assume PTRACE_DETACH_ASYNC is trivial, but it is not. Lets forget it for now.
> > And. Currently there is no way to detach a zombie leader. Perhaps we > > should change do_wait(), but it is not clear what should we do if the > > tracer is the real parent (we already discussed this a bit). > > Hmmm... maybe just allow detaching zombie leader?
Yes, I think we should do this.
If we change PTRACE_DETACH (or add the new request) to allow this, then I think it it should detach any zombie, leader or not.
Or we can change do_wait() to detach a zombie leader. In this case it is not clear what should we do if the debugger is the real parent. Perhaps do_wait() should do the same: detach a leader (but not reap). When the last thread does, the real parent will be notified again. IOW, wait(tgid) can succeed twice.
> As it's guaranteed > to be not running, we don't have problem with ptrace_disable.
Agreed. In fact it can be running, but it can't return to the user-space, and I think this is enough.
ptrace_detach()->ptrace_disable() can race with SIGKILL anyway, this means it should safe to call it if the tracee is exiting/exited.
Oleg.
| |