From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [RFC][v8][PATCH 3/10]: Make pid_max a pid_ns property Date: Tue, 13 Oct 2009 17:09:51 +0400 Message-ID: <4AD47C1F.7040703@openvz.org> References: <20091013044925.GA28181@us.ibm.com> <20091013045041.GC28435@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20091013045041.GC28435-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 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: Sukadev Bhattiprolu Cc: randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, arnd-r2nGTMty4D4@public.gmane.org, Containers , Nathan Lynch , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Louis.Rilling-aw0BnHfMbSpBDgjK7y7TUQ@public.gmane.org, "Eric W. Biederman" , kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org, hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org, mingo-X9Un+BFzKDI@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, Alexey Dobriyan , roland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, Pavel Emelyanov List-Id: linux-api@vger.kernel.org Sukadev Bhattiprolu wrote: > > From: Serge Hallyn > Subject: [RFC][v8][PATCH 3/10]: Make pid_max a pid_ns property > > Remove the pid_max global, and make it a property of the > pid_namespace. When a pid_ns is created, it inherits > the parent's pid_ns. > > Fixing up sysctl (trivial akin to ipc version, but > potentially tedious to get right for all CONFIG* > combinations) is left for later. > > Changelog[v2]: > - Port to newer kernel > - Make pid_max a local variable in alloc_pidmap() to simplify code/patch > > Signed-off-by: Serge Hallyn > Signed-off-by: Sukadev Bhattiprolu Not that I'm about to slow down or block the process, but... frankly I don't see the reason for doing so. Why should we? Especially taking into account, that we essentially cannot change thin in the namespace level 3 and deeper?