> 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. > agree > 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. > This works. But: - we put extra burden on subsystem developers. - hierarchy_mutex can't do what we expect, and it's a bit subtle. - there won't be performance problem or potential lock issue to use cgroup_mutex in subsys' simple write functions, so I don't think we have to avoid cgroup_mutex here. In memcg, both mem_cgroup_hierarchy_write() and mem_cgroup_swappiness_write() check cgrp->children list, similar to ipv4_write() here. And I'm going to fix swappiness_write() for it doesn't hold cgroup_lock(), but if avoiding cgroup_lock() is the direction, then I have to use this alternative way you sugguested. > 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