Nikolay Borisov <kernel@xxxxxxxx> writes: > On 11/01/2016 05:01 PM, Eric W. Biederman wrote: >> I think conceptually this can work. >> >> Reading through the code I don't see anything capturing the current >> processes RLIMIT_NPROC when creating a new user namespace. Which is >> critical if the limits are going to be enforced hierarchically. > > Right, now the question is whether the limits can in fact be enforced > hierarchically. Because what's really happening is that the actual limit > is set per-process (in task->signal->rlim[limit].rlim_cur). However, the > signal struct is being copied when we fork a new process. > > With such a setup nothing prevents the parent process to die and thus > loosing the hierarchical relationship. Otherwise a rework would need to > be done to move the rlimits in the struct user_namespace. Essentially > this is an open problem and it would require some more design thinking > to get it right. The only point I see in using the ucount infrastructure is if we limit a user namespace to the number of processes the creator of user namespace was allowed to create. Thus making it impossible to escape your limit by creating a user namespace and using multiple users. Your current patch achieves the opposite. Making it even easier to escape your current rlimit which is a regression and unacceptable. >> >> I have a small concern that we toss the per user accounting entirely as >> that means we loose a little in ensuring one uid does not have too many >> processes. But that is comparatively minor. >> >> I am buried with Kernel Summit and Plumbers this week, so I will be slow >> on review etc. >> >> But overall I think this a viable approach assuming there are no >> performance issues in structuring things this way. > > According to my experiments (see reply I sent to Serge) ucount doesn't > introduce major performance bottlenecks. If you have ideas for a > particular usecases worth investigating I'm happy to do it. But plain > old forking should be sufficient. Which is nice but you have only measured half of what is interesting. Until there is hierarchical limit enforcement this is uninteresting. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
