Re: [PATCH 3/4] coredump: kill ptrace related stuff

[Oleg Nesterov <oleg@tv-sign.ru>]

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.