[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1bpjyrkep.fsf@fess.ebiederm.org>
Date: Thu, 22 Oct 2009 18:03:42 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc: Matt Helsley <matthltc@...ibm.com>,
Oren Laadan <orenl@...rato.com>,
Daniel Lezcano <daniel.lezcano@...e.fr>,
randy.dunlap@...cle.com, arnd@...db.de, linux-api@...r.kernel.org,
Containers <containers@...ts.linux-foundation.org>,
Nathan Lynch <nathanl@...tin.ibm.com>,
linux-kernel@...r.kernel.org, Louis.Rilling@...labs.com,
kosaki.motohiro@...fujitsu.com, hpa@...or.com, mingo@...e.hu,
torvalds@...ux-foundation.org,
Alexey Dobriyan <adobriyan@...il.com>, roland@...hat.com,
Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: [RFC][v8][PATCH 0/10] Implement clone3() system call
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com> writes:
> Eric W. Biederman [ebiederm@...ssion.com] wrote:
> | +static int set_pidmap(struct pid_namespace *pid_ns, int target)
> | +{
> | + if (target >= pid_max)
> | + return -1;
>
> I am changing this and the next return to 'return -EINVAL', to match
> an earlier patch in my patchset.
>
> | + if (target < RESERVED_PIDS)
>
> Should we replace RESERVED_PIDS with 0 ? We currently allow new
> containers to have pids 1..32K in the first pass and in subsequent
> passes assign starting at RESERVED_PIDS.
If it is a preexisting namespace pid namespace removing the RESERVED_PIDS
check removes most if not all of the point of RESERVED_PIDS.
In a new fresh pid namespace I have no problem with not performing
the RESERVED_PIDS check.
So I guess that makes the check.
if ((target < RESERVED_PIDS) && pid_ns->last_pid >= RESERVED_PIDS)
return -EINVAL;
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists