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

[Christian Brauner]

On Wed, Feb 18, 2026 at 12:25:26PM +0100, Oleg Nesterov wrote:
> 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.

Good point, I think makes sense to not allow CLONE_PARENT with this.