Messages in this thread | | | Date | Mon, 27 Jun 2011 16:21:36 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/8] kill tracehook_notify_death() |
| |
Hi,
On 06/27, Tejun Heo wrote: > > On Sun, Jun 26, 2011 at 10:51:57PM +0200, Oleg Nesterov wrote: > > > Yeap, we've discussed this before and this indeed is odd. However, is > > > there something ptracer can't do with PTRACE_EVENT_EXIT instead? > > > > Firstly, I think PTRACE_EVENT_EXIT should not stop the tracee if it > > was SIGKILL'ed. Even if the tracee stops, it can be killed later. > > The tracer can't detach after that, it can't even wait() to detecte > > a zombie leader. > > For SIGKILL, yes, it is different, but if PTRACE_EVENT_EXIT is enough > for all other cases, I think we're mostly set.
I think this is not that simple. I already mentioned this before, I think we need a separate discussion. I'll try to return to this in a few days.
Firstly, we should decide when PTRACE_EVENT_EXIT should stop, and when it shouldn't. In this discussion I'll assume sys_exit_group() should respect PTRACE_EVENT_EXIT.
> BTW, it seems like we > would actually stop at PTRACE_EVENT_EXIT even after SIGKILL. This is > wrong & racy.
Yes! because the tracee can call ptrace_stop() after the pending SIGKILL was already dequeued from task->pending, this fools schedule()->signal_pending_state().
So, __fatal_signal_pending() is too "weak",
> may_ptrace_stop() should be checking for > sigkill_pending(), right?
Yes, but at the same time even __fatal_signal_pending() is too strong! What if the tracee exits on its own, and its sys_exit() races with exit_group() from another thread? In this case I think it should stop, but __fatal_signal_pending() is true.
And worse. What if the tracee stops in PTRACE_EVENT_EXIT, and _then_ another thread does sys_exit_group()? The tracee will be "killed". I do not think this is right. I think the "implicit" SIGKILL in this case should _not_ wake up the tracee. Only the real SIGKILL (or any fatal signal which mutates to SIGKILL). Otherwise we simply can't guarantee PTRACE_EVENT_EXIT works "reliably" in this case.
We have signal_group_exit()/SIGNAL_GROUP_EXIT. I think we also need SIGNAL_THE_REAL_SIGKILL_WAS_SENT flag. Note also we have the similar problems with the coredump. SIGKILL should abort it. Also, we should define what TIF_SIGPENDIND and interruptible wait mean after exit_signals() and/or exit_notify(). Some drivers (tty? I do not remember) expect that the exiting task can do wait_event_interruptible() and react to ^C.
> I don't have > any major problem with the original. Please go ahead.
Thanks. Can I add your reviewed-by/acked-by ?
Oleg.
| |