Re: [PATCH 4/8] job control: Allow access to job control eventsthrough ptracees

[Oleg Nesterov]

On 03/08, Tejun Heo wrote:
>
> Currently a real parent can't access job control stopped/continued
> events through a ptraced child.  This utterly breaks job control when
> the children are ptraced.

Yes. This is what we need.

Oh. I'll try to recheck this all once again later, there are too many
combinations we should worry about. But looks correct.

Minor problem:

> One situation to be careful about is when the real parent is ptracing.
> The parent is the recipient of both ptrace and job control stop events
> and one stop can be reported as both job control and ptrace stops.  As
> this can break the current ptrace users, suppress job control stopped
> events for these cases.

Yes, but

> @@ -1580,15 +1582,37 @@ static int wait_consider_task(struct wait_opts *wo, int ptrace,
>  			wo->notask_error = 0;
>  	} else {
>  		/*
> +		 * If %current is ptracing @p, hide group stop/continued
> +		 * state when looking at @p as the real parent; otherwise,
> +		 * a single stop can be reported twice as group and ptrace
> +		 * stops.
> +		 *
> +		 * If a ptracer wants to distinguish the two events for its
> +		 * own children, it should create a separate task which
> +		 * takes the role of real parent.
> +		 */
> +		if (likely(!ptrace) && task_ptrace(p) && p->parent == current)
> +			return 0;

This doesn't look exactly right. Ignoring __WNOTHREAD, do_wait() should work
the same way for every thread in parent/debugger's thread group. IOW, we
should probably check same_thread_group(p->parent, p->real_parent) instead
of "== current".



OTOH, this is minor, perhaps we do not care. And  we have more oddities
like this. In fact I think we should just change ptrace_reparented() to
use same_thread_group(), this makes wait_task_zombie() more consistent.
But, again, this needs another discussion and off-topic right now.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/