Quoting Pavel Emelyanov (xe...@openvz.org): > Sukadev Bhattiprolu wrote: > > > > From: Serge Hallyn <se...@us.ibm.com> > > 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 <se...@us.ibm.com> > > Signed-off-by: Sukadev Bhattiprolu <suka...@us.ibm.com> > > Not that I'm about to slow down or block the process, but...
This patch isn't a core part of the clone_with_pid functionality, just something Eric has asked for. So I don't object to dropping it. But I disagree with Alexey's claim that this isn't a namespace property. It should be. > 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? What do you mean by that? With this patchset we're not, it's true, but we trivially can - even now, userspace can simply not give the container CAP_SYS_ADMIN or write access to the sysctl so they can't do any more CLONE_NEWPIDS or change the sysctl. -serge _______________________________________________ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel