On Wed, Aug 25, 2010 at 2:35 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > So am I correct to assume that this change is now needed in 2.6.36, and > unneeded in 2.6.35? > > Can it affect the userspace<->kernel API in amy manner? If so, it > should be backported into earlier kernels to reduce the number of > incompatible kernels out there. AFAICS it shouldn't affect any existing APIs, either in-kernel or to userspace - it just makes the existing function cgroup_attach_task_current_cg() a specialization of a more generic new function. > > Paul, did you have any comments? Other than the language being a bit confusing, it seems fine. I'd probably word the patch description as: Add cgroup_attach_task_all() The existing cgroup_attach_task_current_cg() API is called by a thread to attach another thread to all of its cgroups; this is unsuitable for cases where a privileged task wants to attach itself to the cgroups of a less privileged one, since the call must be made from the context of the target task. This patch adds a more generic cgroup_attach_task_all() API that allows both the source task and to-be-moved task to be specified. cgroup_attach_task_current_cg() becomes a specialization of the more generic new function. Acked-by: Paul Menage <menage@xxxxxxxxxx> _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
