lkml.org 
[lkml]   [2022]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Potentially undesirable interactions between vfork() and time namespaces
On Fri, Sep 02, 2022 at 07:39:28PM +0300, Alexey Izbyshev wrote:

<snip>

> > > @@ -2043,18 +2043,6 @@ static __latent_entropy struct task_struct
> > > *copy_process(
> > > return ERR_PTR(-EINVAL);
> > > }
> > >
> > > - /*
> > > - * If the new process will be in a different time namespace
> > > - * do not allow it to share VM or a thread group with the forking
> > > task.
> > > - *
> > > - * On vfork, the child process enters the target time namespace only
> > > - * after exec.
> > > - */
> > > - if ((clone_flags & (CLONE_VM | CLONE_VFORK)) == CLONE_VM) {
> > > - if (nsp->time_ns != nsp->time_ns_for_children)
> > > - return ERR_PTR(-EINVAL);
> > > - }
> >
> > pls don't remove this part. It was one of the concerns that vfork
> > doesn't work after unshare(CLONE_NEWTIME), but it is one of the standard
> > ways of creating a new process. For example, posix_spawn uses it.
> >
> What do you mean? On the contrary, removing this restriction of the original
> time namespace implementation allows vfork(), pthread_create() and the like,
> solving the issue with posix_spawn() as well.
>

Sorry, I was not woken up completely and decided that it just reverted
the change that allows vfork. Now, I see that it removes this
restriction completely. So it looks good to me.

Thanks,
Andrei.

\
 
 \ /
  Last update: 2022-09-02 19:22    [W:0.853 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site