All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <khlebnikov@openvz.org>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Oleg Nesterov <oleg@redhat.com>, Tejun Heo <tj@kernel.org>,
	Pedro Alves <pedro@codesourcery.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	James Bottomley <jbottomley@parallels.com>
Subject: Re: [RFC][PATCH 0/3] fork: Add the ability to create tasks with	given pids
Date: Sun, 27 Nov 2011 13:41:37 +0400	[thread overview]
Message-ID: <4ED205D1.5060407@openvz.org> (raw)
In-Reply-To: <4ECF6AA0.80006@parallels.com>

Pavel Emelyanov wrote:
> OK, here's another proposal that seem to suit all of us:
>
> 1. me wants to clone tasks with pids set
> 2. Pedro wants to fork task with not changing pids and w/o root perms
> 3. Oleg and Tejun want to have little intrusion into fork() path
>
> The proposal is to implement the PR_RESERVE_PID prctl which allocates and puts a
> pid on the current. The subsequent fork() uses this pid, this pid survives and keeps
> its bit in the pidmap after detach. The 2nd fork() after the 1st task death thus
> can reuse the same pid again. This basic thing doesn't require root perms at all
> and safe against pid reuse problems. When requesting for pid reservation task may
> specify a pid number it wants to have, but this requires root perms (CAP_SYS_ADMIN).
>
> Pedro, I suppose this will work for your checkpoint feature in gdb, am I right?
>
> Few comments about intrusion:
>
>   * the common path - if (pid !=&init_struct_pid) - on fork is just modified
>   * we have -1 argument to copy_process
>   * one more field on struct pid is OK, since it size doesn't change (32 bit level is
>     anyway not required, it's OK to reduce on down to 16 bits)
>   * no clone flags extension
>   * no new locking - the reserved pid manipulations happen under tasklist_lock and
>     existing common paths do not require more of it
>   * yes, we have +1 member on task_struct :(
>
> Current API problems:
>
>   * Only one fork() with pid at a time. Next call to PR_RESERVE_PID will kill the
>     previous reservation (don't know how to fix)
>   * No way to fork() an init of a pid sub-namespace with desired pid in current
>     (can be fixed for a flag for PR_RESERVE_PID saying that we need a pid for a
>      namespace of a next level)

>   * No way to grab existing pid for reserve (can be fixed, if someone wants this)

We can add flag to sys_wait4(), and stash pid in wait_task_zombie(), right before release_task()
code will looks something like this:

-       if (p != NULL)
+       if (p != NULL) {
+               if ((wo->wo_flags & WCATCHPID) && !current->pid_stash) {
+                       struct pid *pid = task_pid(p);
+
+                       pid->flags |= PID_STASHED;
+                       current->pid_stash = get_pid(pid);
+               }
                 release_task(p);
+       }

And next fork() creates child with the same pid.
So, struct pid will work like boomerang =)

  parent reply	other threads:[~2011-11-27  9:41 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-17 11:41 [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids Pavel Emelyanov
2011-11-17 11:42 ` [PATCH 1/3] pids: Make alloc_pid return error Pavel Emelyanov
2011-11-17 11:42 ` [PATCH 2/3] pids: Split alloc_pidmap into parts Pavel Emelyanov
2011-11-17 11:43 ` [PATCH 3/3] pids: Make it possible to clone tasks with given pids 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
2011-11-17 15:49 ` [RFC][PATCH 0/3] fork: Add the ability to create " Oleg Nesterov
2011-11-17 16:01   ` Pavel Emelyanov
2011-11-17 16:02     ` Oleg Nesterov
2011-11-18 23:30     ` Tejun Heo
2011-11-21  9:15       ` Pavel Emelyanov
2011-11-21 22:50         ` Tejun Heo
2011-11-22 11:11           ` Pavel Emelyanov
2011-11-22 12:04             ` Pedro Alves
2011-11-22 15:33               ` Tejun Heo
2011-11-23 16:20                 ` Pedro Alves
2011-11-23 16:24                   ` Tejun Heo
2011-11-23 17:26                     ` Oleg Nesterov
2011-11-23 17:37                       ` Tejun Heo
2011-11-23 18:19                     ` Pavel Emelyanov
2011-11-23 20:14                       ` Pavel Emelyanov
2011-11-24 17:31                         ` Oleg Nesterov
2011-11-25 10:14                           ` Pavel Emelyanov
2011-11-25 16:22                             ` Oleg Nesterov
2011-11-25 16:44                               ` Pavel Emelyanov
2011-11-25 16:54                                 ` Oleg Nesterov
2011-11-25 17:03                                   ` Pavel Emelyanov
2011-11-25 22:36                                     ` Pedro Alves
2011-11-27 16:24                                       ` [RFC][PATCH 0/3] fork: Add the ability to create tasks with?given pids Oleg Nesterov
2011-11-27  9:41                             ` Konstantin Khlebnikov [this message]
2011-11-27 17:34                               ` [RFC][PATCH 0/3] fork: Add the ability to create tasks with given pids Oleg Nesterov
2011-11-27 18:47                             ` Tejun Heo
2011-11-28 10:38                               ` Pavel Emelyanov
2011-11-28 16:25                                 ` Tejun Heo
2011-11-22 15:23             ` Tejun Heo
2011-11-22 15:29               ` Tejun Heo
2011-11-22 16:30               ` Pavel Emelyanov
2011-11-22 16:44                 ` Linus Torvalds
2011-11-22 19:29                   ` Pavel Emelyanov
2012-01-26 23:28                   ` Kay Sievers
2011-11-22 21:16           ` Oleg Nesterov

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=4ED205D1.5060407@openvz.org \
    --to=khlebnikov@openvz.org \
    --cc=gorcunov@openvz.org \
    --cc=jbottomley@parallels.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=pedro@codesourcery.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.