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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
