public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2009-08-13  7:59 UTC|newest]

Thread overview: 18+ 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
2009-08-10 14:54   ` Pavel Machek
2009-08-10 15:07     ` Serge E. Hallyn
2009-08-10 22:26     ` Sukadev Bhattiprolu
2009-08-13  3:45 ` [RFC][v4][PATCH 0/7] clone_with_pids() system call Eric W. Biederman
2009-08-13  8:00   ` Sukadev Bhattiprolu [this message]
2009-08-13  9:05     ` Eric W. Biederman
2009-08-13 19:46       ` Serge E. Hallyn
2009-08-21 16:11         ` Serge E. Hallyn
2009-08-18  3:31       ` Sukadev Bhattiprolu
2009-08-13 13:32   ` Serge E. Hallyn

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox