Thread (54 messages) 54 messages, 5 authors, 2012-11-02

Re: [PATCH 3/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create()

From: Michal Hocko <hidden>
Date: 2012-11-01 15:05:40
Also in: lkml

On Thu 01-11-12 07:52:24, Tejun Heo wrote:
Hey, Michal.

On Thu, Nov 1, 2012 at 2:16 AM, Michal Hocko [off-list ref] wrote:
quoted
I am not sure I understand. What does deactivate_super has to do with
the above suggestion? cgroup_lock_live_group will take the cgroup_mutex
on the success or frees the previously allocated&unused memory. The
only thing I was suggesting is to do cgroup_lock_live_group first and
allocate the cgroup only if it doesn't fail.
It complicates updates to the error exit path.
Still don't get it, sorry. What prevents us to do:
static long cgroup_create(struct cgroup *parent, struct dentry *dentry,
                             umode_t mode)
{
        struct cgroup *cgrp;
        struct cgroupfs_root *root = parent->root;
        int err = 0;
        struct cgroup_subsys *ss;
        struct super_block *sb = root->sb;

	if (!cgroup_lock_live_group(parent))
		return -ENODEV;

        cgrp = kzalloc(sizeof(*cgrp), GFP_KERNEL);
        if (!cgrp)
                return -ENOMEM;
You end up having to update a lot more and it's not like grabbing lock
first is substantially better in any way, so why bother?
Yes the allocation can sleep if we are short on memory so this can
potentially take long which is not entirely nice but a pointless
allocation is not nice either. Anyway I am asking because I am trying to
understand what is the motivation behind and your explanation about the
error exit path doesn't make much sense to me. So I am either missing
something or we are talking about two different things.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help