Re: [PATCH RFC v3 1/4] clone: add CLONE_AUTOREAP

[Oleg Nesterov <oleg@redhat.com>]

On 02/17, Christian Brauner wrote:
>
> CLONE_AUTOREAP can be combined with CLONE_PIDFD to allow the parent to
> monitor the child's exit via poll() and retrieve exit status via
> PIDFD_GET_INFO. Without CLONE_PIDFD it provides a fire-and-forget
> pattern where the parent simply doesn't care about the child's exit
> status. No exit signal is delivered so exit_signal must be zero.
                                         ^^^^^^^^^^^^^^^^^^^^^^^^

Well, it has no effect if signal->autoreap is true. Probably makes
sense to enforce this rule anyway... but see below.

> @@ -2028,6 +2028,13 @@ __latent_entropy struct task_struct *copy_process(
>  			return ERR_PTR(-EINVAL);
>  	}
>
> +	if (clone_flags & CLONE_AUTOREAP) {
> +		if (clone_flags & CLONE_THREAD)
> +			return ERR_PTR(-EINVAL);
> +		if (args->exit_signal)
> +			return ERR_PTR(-EINVAL);
> +	}
> +
>  	/*
>  	 * Force any signals received before this point to be delivered
>  	 * before the fork happens.  Collect up signals sent to multiple
> @@ -2374,6 +2381,8 @@ __latent_entropy struct task_struct *copy_process(
>  		p->parent_exec_id = current->parent_exec_id;
>  		if (clone_flags & CLONE_THREAD)
>  			p->exit_signal = -1;
> +		else if (clone_flags & CLONE_AUTOREAP)
> +			p->exit_signal = 0;

So this is only needed for the CLONE_PARENT|CLONE_AUTOREAP case. Do we
really need to support this case? Not that I see anything wrong, but let
me ask anyway.

OTOH, what if a CLONE_AUTOREAP'ed child does clone(CLONE_PARENT) ?
in this case args->exit_signal is ignored, so the new child will run
with exit_signal == 0 but without signal->autoreap. This means it will
become a zombie without sending a signal. Again, I see nothing really
wrong, just this looks a bit confusing to me.

Oleg.