> > I think the only way to make hierarchy_mutex works for this issue is: > > @@ -2403,16 +2403,18 @@ static long cgroup_create(struct cgroup *parent, struct > if (notify_on_release(parent)) > set_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags); > > + cgroup_lock_hierarchy(root); > + > for_each_subsys(root, ss) { > struct cgroup_subsys_state *css = ss->create(ss, cgrp); > if (IS_ERR(css)) { > + cgroup_unlock_hierarchy(root); > err = PTR_ERR(css); > goto err_destroy; > } > init_cgroup_css(css, ss, cgrp); > } > > - cgroup_lock_hierarchy(root); > list_add(&cgrp->sibling, &cgrp->parent->children); > cgroup_unlock_hierarchy(root); > root->number_of_cgroups++; > That would be possible, but I'm not sure that extending hierarchy_mutex across all the create calls is a good idea - it's meant to be very lightweight. OK, an alternative way to avoid cgroup_lock() is for the spinlock-protected state in ipcgroup to be the address and the count of active children. create() does: lock parent css->addr = parent->addr parent->child_count++; unlock parent and write does: lock css if (!css->child_count) { css->addr = new_addr } else { report error; } unlock css Paul _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers