All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Glauber Costa <glommer@parallels.com>,
	Nathan Lynch <ntl@pobox.com>,
	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: Sun, 13 Nov 2011 20:28:48 +0100	[thread overview]
Message-ID: <20111113192848.GC4633@redhat.com> (raw)
In-Reply-To: <4EBD57D4.1060503@parallels.com>

On 11/11, Pavel Emelyanov wrote:
>
> Hm, so intrusiveness is your main concern here, I see.

To me, this is important.

> OK, let's assume we go with sysctl setting the last_pid.
>
> One of the major concerns with previous attempts have been - someone creates
> a process with a pid that was in use by some app recently and screws things
> up with pid reuse.

Good point.

> My approach solves this,

Yes. Although, can't resist, in a subtle way (imho). CLONE_CHILD_USEPIDS
stops working after a clone() without this flag.

> how can sysctl handle it? Allowing
> the last_pid change by the CAP_SYA_ADMIN

Yes, when I suggested set_last_pid I assumed that it needs CAP_SYS_ADMIN.

> only is not an option, since people
> are looking forward to non-root restore.

But CLONE_NEWPID needs CAP_SYS_ADMIN too ?

Anyway, I do not pretend I understand the problem space. And probably
it would be more convenient to change the creds before forking some
children with the predefined pids, I do not know.

So yes, I agree, CLONE_CHILD_USEPIDS wins here. Perhaps set_last_pid
needs another sysctl(set_last_pid_allowed)/whatever, or another idea.
Or we should use CLONE_CHILD_USEPIDS ;)

Let me repeat. It is not that I strongly against CLONE_CHILD_USEPIDS
(although yes, I can't say personally I like it very much ;). Just
I am trying to ensure we can't make something more clear/clean/simple,
at least from the kernel pov. Especially because you are trying to
establish the new user-visible API.

Oleg.


  reply	other threads:[~2011-11-13 19:33 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 [this message]
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
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=20111113192848.GC4633@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.