From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, Oren Laadan <orenl@cs.columbia.edu>,
serue@us.ibm.com, Alexey Dobriyan <adobriyan@gmail.com>,
Pavel Emelyanov <xemul@openvz.org>, Andrew Morton <akpm@osdl.org>,
torvalds@linux-foundation.org, mikew@google.com, mingo@elte.hu,
hpa@zytor.com, Containers <containers@lists.linux-foundation.org>,
sukadev@us.ibm.com, Oleg Nesterov <oleg@redhat.com>
Subject: Re: [RFC][v4][PATCH 0/7] clone_with_pids() system call
Date: Thu, 13 Aug 2009 01:00:49 -0700 [thread overview]
Message-ID: <20090813080049.GA16639@us.ibm.com> (raw)
In-Reply-To: <m1vdks5qc8.fsf@fess.ebiederm.org>
Eric W. Biederman [ebiederm@xmission.com] wrote:
| Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> writes:
|
| > === NEW CLONE() SYSTEM CALL:
| >
| > To support application checkpoint/restart, a task must have the same pid it
| > had when it was checkpointed. When containers are nested, the tasks within
| > the containers exist in multiple pid namespaces and hence have multiple pids
| > to specify during restart.
| >
| > This patchset implements a new system call, clone_with_pids() that lets a
| > process specify the pids of the child process.
| >
| > Patches 1 through 5 are helpers and we believe they are needed for application
| > restart, regardless of the kernel implementation of application restart.
|
| I'm not very impressed.
|
| - static int alloc_pidmap(struct pid_namespace *pid_ns)
| + static int alloc_pidmap(struct pid_namespace *pid_ns, int pid_max, int last_pid)
|
| Do that.
|
| That is pass in pid_max and last_pid, and you don't have to do weird
| things in alloc_pidmap, and no set_pidmap is needed.
But last_pid is from the pid_ns. Do you mean to have alloc_pidmap()
take a pid_min and pid_max and when choosing a specific pid, have
pid_min == pid_max == target_pid ?
|
| No changes to copy_process are needed it already takes a struct pid
| argument.
I see your point about passing in both 'struct pid*' and target_pids[].
But in the common case the struct pid passed into copy_process() is
NULL - allocating pid in do_fork() would significantly alter the
existing control flow - no ? alloc_pid() assumes any new pid namespace
has been created - in copy_namespaces(). Moving the alloc_pid() to
do_fork() would require parsing clone_flags in do_fork() and pulling
pid namespace code out of copy_namespaces().
|
| I haven't been following closely what is gained by having a clone_with_pids
| syscall?
When restarting an application from a checkpoint, the application must get
the same pid it had at the time of checkpoint. clone_with_pids() would be
used during restart so the child can be created with a specific set of pids.
|
| As for new namespaces that don't need to happen at process creation time
| (which is just about anything that is left) we can create a new syscall that
| unshares just that one.
|
Ok. If all new namespaces can be handled with a variant of unshare(), we can
decouple clone_with_pids() from the clone-flags issue.
|
| Eric
next prev parent reply other threads:[~2009-08-13 7:59 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-07 6:11 [RFC][v4][PATCH 0/7] clone_with_pids() system call Sukadev Bhattiprolu
2009-08-07 6:12 ` [RFC][v4][PATCH 1/7]: Factor out code to allocate pidmap page Sukadev Bhattiprolu
2009-08-07 6:12 ` [RFC][v4][PATCH 2/7]: Have alloc_pidmap() return actual error code Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 3/7]: Add target_pid parameter to alloc_pidmap() Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 4/7]: Add target_pids parameter to alloc_pid() Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 5/7]: Add target_pids parameter to copy_process() Sukadev Bhattiprolu
2009-08-07 6:14 ` [RFC][v4][PATCH 6/7]: Define do_fork_with_pids() Sukadev Bhattiprolu
2009-08-07 6:15 ` [RFC][v4][PATCH 7/7]: Define clone_with_pids syscall Sukadev Bhattiprolu
[not found] ` <20090807061517.GG20672-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-10 14:54 ` Pavel Machek
2009-08-10 14:54 ` Pavel Machek
2009-08-10 15:07 ` Serge E. Hallyn
[not found] ` <20090810145425.GA1378-+ZI9xUNit7I@public.gmane.org>
2009-08-10 15:07 ` Serge E. Hallyn
2009-08-10 22:26 ` Sukadev Bhattiprolu
2009-08-10 22:26 ` Sukadev Bhattiprolu
[not found] ` <20090807061103.GA19343-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-07 6:12 ` [RFC][v4][PATCH 1/7]: Factor out code to allocate pidmap page Sukadev Bhattiprolu
2009-08-07 6:12 ` [RFC][v4][PATCH 2/7]: Have alloc_pidmap() return actual error code Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 3/7]: Add target_pid parameter to alloc_pidmap() Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 4/7]: Add target_pids parameter to alloc_pid() Sukadev Bhattiprolu
2009-08-07 6:13 ` [RFC][v4][PATCH 5/7]: Add target_pids parameter to copy_process() Sukadev Bhattiprolu
2009-08-07 6:14 ` [RFC][v4][PATCH 6/7]: Define do_fork_with_pids() Sukadev Bhattiprolu
2009-08-07 6:15 ` [RFC][v4][PATCH 7/7]: Define clone_with_pids syscall Sukadev Bhattiprolu
2009-08-13 3:45 ` [RFC][v4][PATCH 0/7] clone_with_pids() system call Eric W. Biederman
2009-08-13 3:45 ` Eric W. Biederman
2009-08-13 8:00 ` Sukadev Bhattiprolu [this message]
[not found] ` <20090813080049.GA16639-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-13 9:05 ` Eric W. Biederman
2009-08-13 9:05 ` Eric W. Biederman
2009-08-13 19:46 ` Serge E. Hallyn
2009-08-21 16:11 ` Serge E. Hallyn
[not found] ` <20090813194616.GA10493-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-08-21 16:11 ` Serge E. Hallyn
2009-08-18 3:31 ` Sukadev Bhattiprolu
[not found] ` <m1vdks2iea.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-08-13 19:46 ` Serge E. Hallyn
2009-08-18 3:31 ` Sukadev Bhattiprolu
[not found] ` <m1vdks5qc8.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-08-13 8:00 ` Sukadev Bhattiprolu
2009-08-13 13:32 ` Serge E. Hallyn
2009-08-13 13:32 ` Serge E. Hallyn
-- strict thread matches above, loose matches on Subject: below --
2009-08-07 6:11 Sukadev Bhattiprolu
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=20090813080049.GA16639@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=adobriyan@gmail.com \
--cc=akpm@osdl.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikew@google.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=orenl@cs.columbia.edu \
--cc=serue@us.ibm.com \
--cc=sukadev@us.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=xemul@openvz.org \
/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.