[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190802124738.GC20111@redhat.com>
Date: Fri, 2 Aug 2019 14:47:38 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Adrian Reber <areber@...hat.com>
Cc: Christian Brauner <christian@...uner.io>,
Eric Biederman <ebiederm@...ssion.com>,
Pavel Emelianov <xemul@...tuozzo.com>,
Jann Horn <jannh@...gle.com>,
Dmitry Safonov <0x7f454c46@...il.com>,
linux-kernel@...r.kernel.org, Andrei Vagin <avagin@...il.com>,
Mike Rapoport <rppt@...ux.ibm.com>,
Radostin Stoyanov <rstoyanov1@...il.com>
Subject: Re: [PATCH v2 1/2] fork: extend clone3() to support CLONE_SET_TID
On 08/02, Adrian Reber wrote:
>
> On Wed, Jul 31, 2019 at 07:41:36PM +0200, Oleg Nesterov wrote:
> > But the main question is how it can really help if ns->level > 0, unlikely
> > CRIU will ever need to clone the process with the same pid_nr == set_tid
> > in the ns->parent chain.
>
> Not sure I understand what you mean. For CRIU only the PID in the PID
> namespace is relevant.
If it runs "inside" this namespace. But in this case alloc_pid() should
use nr == set_tid only once in the main loop, when i == ns->level.
It doesn't need to have the same pid_nr in the parent pid namespace.
And in fact we should not allow criu (or anything else) to control the child's
pid_nr in the parent(s) namespace.
Right?
> > So may be kernel_clone_args->set_tid should be pid_t __user *set_tid_array?
> > Or I missed something ?
>
> Not sure why and how an array would be needed. Could you give me some
> more details why you think this is needed.
IIURC, criu can restore the process tree along with nested pid namespaces.
how can this patch help in this case?
But again, perhaps I missed something. I forgot everything about criu.
Oleg.
Powered by blists - more mailing lists