All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Adrian Reber <areber@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	Pavel Emelyanov <ovzxemul@gmail.com>,
	Jann Horn <jannh@google.com>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	linux-kernel@vger.kernel.org, Andrei Vagin <avagin@gmail.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Radostin Stoyanov <rstoyanov1@gmail.com>
Subject: Re: [PATCH v7 1/2] fork: extend clone3() to support setting a PID
Date: Mon, 11 Nov 2019 17:14:59 +0100	[thread overview]
Message-ID: <20191111161458.fjodxyx566dar6ob@wittgenstein> (raw)
In-Reply-To: <20191111154028.GF514519@dcbz.redhat.com>

On Mon, Nov 11, 2019 at 04:40:28PM +0100, Adrian Reber wrote:
> On Mon, Nov 11, 2019 at 04:25:15PM +0100, Oleg Nesterov wrote:
> > On 11/11, Adrian Reber wrote:
> > >
> > > v7:
> > >  - changed set_tid to be an array to set the PID of a process
> > >    in multiple nested PID namespaces at the same time as discussed
> > >    at LPC 2019 (container MC)
> > 
> > cough... iirc you convinced me this is not needed when we discussed
> > the previous version ;) Nevermind, probably my memory fools me.
> 
> You are right. You suggested the same thing and we didn't listen ;)
> 
> > So far I only have some cosmetic nits,
> 
> Thanks for the quick review. I will try to apply your suggestions.
> 
> > > @@ -175,6 +187,18 @@ struct pid *alloc_pid(struct pid_namespace *ns)
> > >
> > >  	for (i = ns->level; i >= 0; i--) {
> > >  		int pid_min = 1;
> > > +		int t_pos = 0;
> >                     ^^^^^
> > 
> > I won't insist, but I'd suggest to cache set_tid[t_pos] instead to make
> > the code a bit more simple.
> > 
> > > @@ -186,12 +210,24 @@ struct pid *alloc_pid(struct pid_namespace *ns)
> > >  		if (idr_get_cursor(&tmp->idr) > RESERVED_PIDS)
> > >  			pid_min = RESERVED_PIDS;
> > 
> > You can probably move this code into the "else" branch below.
> > 
> > IOW, something like
> > 
> > 
> > 	for (i = ns->level; i >= 0; i--) {
> > 		int xxx = 0;
> > 
> > 		if (set_tid_size) {
> > 			int pos = ns->level - i;
> > 
> > 			xxx = set_tid[pos];
> > 			if (xxx < 1 || xxx >= pid_max)
> > 				return ERR_PTR(-EINVAL);
> > 			/* Also fail if a PID != 1 is requested and no PID 1 exists */
> > 			if (xxx != 1 && !tmp->child_reaper)
> > 				return ERR_PTR(-EINVAL);
> > 			if (!ns_capable(tmp->user_ns, CAP_SYS_ADMIN))
> > 				return ERR_PTR(-EPERM);
> > 			set_tid_size--;
> > 		}
> > 
> > 		idr_preload(GFP_KERNEL);
> > 		spin_lock_irq(&pidmap_lock);
> > 
> > 		if (xxx) {
> > 			nr = idr_alloc(&tmp->idr, NULL, xxx, xxx + 1,
> > 					GFP_ATOMIC);
> > 			/*
> > 			 * If ENOSPC is returned it means that the PID is
> > 			 * alreay in use. Return EEXIST in that case.
> > 			 */
> > 			if (nr == -ENOSPC)
> > 				nr = -EEXIST;
> > 		} else {
> > 			int pid_min = 1;
> > 			/*
> > 			 * init really needs pid 1, but after reaching the
> > 			 * maximum wrap back to RESERVED_PIDS
> > 			 */
> > 			if (idr_get_cursor(&tmp->idr) > RESERVED_PIDS)
> > 				pid_min = RESERVED_PIDS;
> > 			/*
> > 			 * Store a null pointer so find_pid_ns does not find
> > 			 * a partially initialized PID (see below).
> > 			 */
> > 			nr = idr_alloc_cyclic(&tmp->idr, NULL, pid_min,
> > 					      pid_max, GFP_ATOMIC);
> > 		}
> > 
> > 		...
> > 
> > This way only the "if (set_tid_size)" block has to play with set_tid_size/set_tid.
> > 
> > note also that this way we can easily allow set_tid[some_level] == 0, we can
> > simply do
> > 
> > 	-	if (xxx < 1 || xxx >= pid_max)
> > 	+	if (xxx < 0 || xxx >= pid_max)
> > 
> > although I don't think this is really useful.
> 
> Yes. I explicitly didn't allow 0 as a PID as I didn't thought it would
> be useful (or maybe even valid).

How do you express: I don't care about a specific pid in pidns level
<n>, just give me a random one? For example,

set_tid[0] = 1234
set_tid[1] = 5678
set_tid[2] = random_pid()
set_tid[3] = 9

Wouldn't that be potentially useful?

Christian

  reply	other threads:[~2019-11-11 16:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11 13:17 [PATCH v7 1/2] fork: extend clone3() to support setting a PID Adrian Reber
2019-11-11 13:17 ` [PATCH v7 2/2] selftests: add tests for clone3() Adrian Reber
2019-11-11 15:25 ` [PATCH v7 1/2] fork: extend clone3() to support setting a PID Oleg Nesterov
2019-11-11 15:40   ` Adrian Reber
2019-11-11 16:14     ` Christian Brauner [this message]
2019-11-11 16:32       ` Oleg Nesterov
2019-11-11 23:08       ` Eric W. Biederman
2019-11-12 10:24         ` Christian Brauner
2019-11-11 16:12 ` Christian Brauner
2019-11-11 20:41 ` Rasmus Villemoes
2019-11-12 15:26   ` Adrian Reber
2019-11-13  8:02   ` Adrian Reber

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=20191111161458.fjodxyx566dar6ob@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=0x7f454c46@gmail.com \
    --cc=areber@redhat.com \
    --cc=avagin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=ovzxemul@gmail.com \
    --cc=rppt@linux.ibm.com \
    --cc=rstoyanov1@gmail.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.