Re: patch] cpusets, cgroups: disallow attaching kthreadd

[David Rientjes <rientjes@google.com>]

On Thu, 20 Oct 2011, Peter Zijlstra wrote:

> >  though, you could devise a 
> > cgroup to just do monitoring or statistics tracking for an aggregate of 
> > tasks and placing kthreadd in such a cgroup would make perfect sense 
> > because then, since children are forked in the same cgroup, you can 
> > monitor or gather statistics for all kthreads.  This can be your only 
> > cgroup on the system.
> 
> I guess you could, but does it really make sense? Also, you could sort
> this by extending the cgroup interface to explicitly distinct between
> controllers and !controllers.
> 

I don't know what the definition of "controllers" is that would separate 
the two, that's why it's left up to the individual cgroups to define their 
own can_attach() function to ensure that the admin isn't doing something 
potentially harmful.

In terms of controlling the set of allowed nodes, we certainly want to 
prohibit PF_THREAD_BOUND threads for cpusets because cpusets can easily 
change that (and spews a nasty warning if set_cpus_allowed_ptr() fails).

In terms of controlling kthreadd forking threads that become stuck with 
PF_THREAD_BOUND, I think Mike's patch is correct for cpusets, since we 
know we don't want its children to become trapped.  All other cgroups, 
unless they have a similar exemption for PF_THREAD_BOUND threads, would 
allow the child to be reassigned by their can_attach() function.  A grep 
for PF_THREAD_BOUND shows no others.