From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nadia Derbey Subject: Re: [RFC PATCH 3/5] use next syscall data to predefine process ids Date: Thu, 10 Jul 2008 10:32:50 +0200 Message-ID: <4875C932.2020503@bull.net> References: <20080708112422.164370000@bull.net> <20080708112458.946320000@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: containers.vger.kernel.org Eric W. Biederman wrote: > Nadia.Derbey-6ktuUTfB/bM@public.gmane.org writes: > > >>[PATCH 03/05] >> >>This patch uses the value written into the next_syscall_data proc file >>as a target upid nr for the next process to be created. >>The following syscalls have a new behavior if next_syscall_data is set: >>. fork() >>. vfork() >>. clone() >> >>In the current version, if the process belongs to nested namespaces, only >>the upper namespace level upid nr is allowed to be predefined, since there >>is not yet a way to take a snapshot of upid nrs at all namespaces levels. >> >>But this can easily be extended in the future. > > > This patch is unnecessary. The and a mess. The existing limits on the pid range should > be enough. We may need to export it via /proc/sys. > Eric, If I correctly understood what you're saying, it means set min = max = target_pid using /proc/sys, i.e. for the whole system: don't you think this might be dangerous: allocating pids will fail for any other running process during the entire period of time where /proc/sys will be set like that. I really think this is a feature that should be confined to a process. Regards, Nadia