[Devel] Re: [PATCH v5 3/3] cgroups: make procs file writable

[Ben Blum]

On Fri, Dec 24, 2010 at 07:08:53AM -0500, Ben Blum wrote:
> On Fri, Dec 24, 2010 at 03:53:31AM -0800, Andrew Morton wrote:
> > On Fri, 24 Dec 2010 06:45:00 -0500 Ben Blum <bblum at andrew.cmu.edu> wrote:
> > 
> > > > kmalloc() is allowed while holding a spinlock and NODEMASK_ALLOC() takes a 
> > > > gfp_flags argument for that reason.
> > > 
> > > Ah, it's only with GFP_KERNEL and friends. So changing the uses in
> > > cpuset_can_attach to GFP_ATOMIC would solve this concern, then?
> > 
> > It would introduce an additional concern.  GFP_ATOMIC is bad, for a
> > number of reasons.  The main one of which is that it is vastly less
> > reliable than GFP_KERNEL.  And making the cpuset code less reliable
> > is a regression, no?
> > 
> > Please try to find a better solution.
> 
> Good point. How about pre-allocating the nodemasks in cpuset_can_attach,
> and having a cpuset_cancel_attach function which can free them up?
> 
> They could be stored in the struct cpuset (protected by cgroup_mutex)
> after being pre-allocated - but also only if a heap-allocation was
> required, so there might need to be an extra interface, like
> "NODEMASK_PREALLOC" (a no-op if heap not required, otherwise allocates
> and stores in the struct cpuset) and "NODEMASK_RETRIEVE"?
> 
> -- Ben

Oh, also, most (not all) times that NODEMASK_ALLOC is used in cpusets,
cgroup_mutex is also held. So how about just using static storage for
them? (There could be a new macro "NODEMASK_ALLOC_STATIC", for use when
the caller can never race against itself.) As long as the call-graph
isn't recursive, there shouldn't be a problem...

-- Ben
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers