Messages in this thread | | | Date | Mon, 10 Apr 2006 17:35:52 +0400 | From | Oleg Nesterov <> | Subject | Re: [PATCH 3/4] coredump: kill ptrace related stuff |
| |
On 04/09, Roland McGrath wrote: > > > With this patch zap_process() sets SIGNAL_GROUP_EXIT while sending > > SIGKILL to the thread group. > > do_coredump has already done this. So you are addressing the case of other > thread groups sharing the mm, right?
Yes,
> > This means that a TASK_TRACED task > > > > 1. Will be awakened by signal_wake_up(1) > > That should always happen regardless of signal->flags, so yes. > > > 2. Can't sleep again via ptrace_notify() > > What makes this be so? What if it's entering a notification event now? > What about exit tracing?
It turns out I misread SIGNAL_GROUP_EXIT check in ptrace_stop(), didn't notice '(->parent->signal != current->signal) ||' before it.
You are right, this is a problem, I need to think about it.
Do you see any solution which doesn't need tasklist_lock to be held while traversing global process list?
> > 3. Can't go to do_signal_stop() after return > > from ptrace_stop() in get_signal_to_deliver() > > This is only true because of the check in get_signal_to_deliver, > which I've said I think should be taken out for other reasons.
Yes, changelog refers to SIGNAL_GROUP_EXIT check in get_signal_to_deliver. However, do_signal_stop() returns 0 when it doesn't see SIGNAL_STOP_DEQUEUED, (which was cleared by SIGNAL_GROUP_EXIT), so I think we don't depend on SIGNAL_GROUP_EXIT check in get_signal_to_deliver. No?
Btw, I don't understand Andrea's patch (and changelog) too.
Oleg.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |