From: Oleg Nesterov <oleg@redhat.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Glauber Costa <glommer@parallels.com>,
Nathan Lynch <ntl@pobox.com>, Tejun Heo <tj@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Serge Hallyn <serue@us.ibm.com>,
Daniel Lezcano <dlezcano@fr.ibm.com>
Subject: Re: [PATCH 3/3] pids: Make it possible to clone tasks with given pids
Date: Fri, 11 Nov 2011 17:39:26 +0100 [thread overview]
Message-ID: <20111111163926.GA25106@redhat.com> (raw)
In-Reply-To: <4EBD461E.1000106@parallels.com>
On 11/11, Pavel Emelyanov wrote:
>
> On 11/11/2011 07:25 PM, Oleg Nesterov wrote:
> >
> > But. Let me repeat the question, what if you do the same with
> > pids[0] = 2 /* anything != 1 */ ? In this case we create the new
> > pid_ns, but its ->child_reaper is NULL. Unless I missed something.
>
> Hm... You're right here. I've missed the fact, then in recent kernels
> child_reaper is set under pid == 1 condition (was clone_flags & CLONE_NEWPID).
Yes, I always hated the "cleanup" which removed CLONE_NEWPID from
copy_process. This is_child_reaper() simply hides CLONE_NEWPID from
grep.
But this is offtopic. We should not create ->child_reaper with pid_nr != 1.
> How about if I fix it by disabling the simultaneous use of CLONE_NEWPID and
> CLONE_CHILD_USEPIDS and checking for last_pid != 1 in the set_pidmap?
I think this should work...
> > Hmm. It seems, we can make a simpler patch to achieve the (roughly)
> > same effect. Without touching copy_process/alloc_pid paths. What if
> > we simply add PR_SET_LAST_PID? (or something else).
> >
> > In this case the new init (created normally) read the pids from image
> > file and does prcrl(PR_SET_LAST_PID, pid-1) before the next fork.
> >
> > What do you think?
>
> This will make it impossible to fork() children on restore in parallel. And
> I don't want to lose this ability :(
Yes, this is true. You need some form of synchronization in user-space.
But, otoh, prctl/sysctl/whatever is much simpler. Both from implementation
pov and from understanding/using. You can even do, say, pthread_create()
to make a thread with the desired tid. And of course I like the fact we
do not add the new hacks into copy_process's paths.
And. If you want to restore the process tree, then these new children
have to cooperate anyway. Say, nobody can clone() without
CLONE_CHILD_USEPIDS before we restore all pids.
Yes, sysctl+clone should be "atomic", but that is all. Does it really
hurt? OK, if nothing else, can't you do somthing like
int fork_with_pid(int pid)
{
int ret;
int pipefd[2];
pipe(pipefd);
retry:
prcrl(PR_SET_LAST_PID, pid-1);
ret = fork();
if (ret == 0) {
/* child, wait from parent's ACK */
read(pipefd[0], 1, NULL);
return 0;
}
/* raced with another user of PR_SET_LAST_PID */
if (unlikely(ret != pid) {
kill(ret, SIGKILL);
waitpid(ret);
goto retry;
}
close(pipefd[1]);
return pid;
}
?
Oleg.
next prev parent reply other threads:[~2011-11-11 16:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-10 17:15 [PATCH 0/3] Introduce the cloning with pids functionality Pavel Emelyanov
2011-11-10 17:15 ` [PATCH 1/3] pids: Make alloc_pid return error Pavel Emelyanov
2011-11-10 18:00 ` Oleg Nesterov
2011-11-11 10:02 ` Pavel Emelyanov
2011-11-10 17:15 ` [PATCH 2/3] pids: Split alloc_pidmap into parts Pavel Emelyanov
2011-11-10 18:12 ` Oleg Nesterov
2011-11-10 17:16 ` [PATCH 3/3] pids: Make it possible to clone tasks with given pids Pavel Emelyanov
2011-11-10 17:30 ` Tejun Heo
2011-11-10 17:36 ` Pavel Emelyanov
2011-11-10 17:45 ` Tejun Heo
2011-11-11 10:04 ` Pavel Emelyanov
2011-11-10 18:46 ` Oleg Nesterov
2011-11-10 18:56 ` Oleg Nesterov
2011-11-11 10:11 ` Pavel Emelyanov
2011-11-11 15:25 ` Oleg Nesterov
2011-11-11 15:58 ` Pavel Emelyanov
2011-11-11 16:06 ` Tejun Heo
2011-11-11 16:10 ` Tejun Heo
2011-11-11 16:18 ` Pavel Emelyanov
2011-11-11 16:22 ` Tejun Heo
2011-11-11 16:49 ` Pavel Emelyanov
2011-11-11 17:02 ` Tejun Heo
2011-11-11 17:13 ` Pavel Emelyanov
2011-11-13 19:28 ` Oleg Nesterov
2011-11-14 10:28 ` Pavel Emelyanov
2011-11-11 16:17 ` Pavel Emelyanov
2011-11-11 16:48 ` Oleg Nesterov
2011-11-11 16:39 ` Oleg Nesterov [this message]
2011-11-11 16:55 ` Pavel Emelyanov
2011-11-13 18:59 ` Oleg Nesterov
-- strict thread matches above, loose matches on Subject: below --
2011-11-17 11:41 [RFC][PATCH 0/3] fork: Add the ability to create " Pavel Emelyanov
2011-11-17 11:43 ` [PATCH 3/3] pids: Make it possible to clone " Pavel Emelyanov
2011-11-17 15:32 ` Oleg Nesterov
2011-11-17 15:49 ` Pavel Emelyanov
2011-11-17 16:00 ` Oleg Nesterov
2011-11-17 17:28 ` Linus Torvalds
2011-11-17 19:04 ` Oleg Nesterov
2011-11-17 18:36 ` Oleg Nesterov
2011-11-18 10:05 ` Pavel Emelyanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111111163926.GA25106@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dlezcano@fr.ibm.com \
--cc=glommer@parallels.com \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ntl@pobox.com \
--cc=serue@us.ibm.com \
--cc=tj@kernel.org \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.