>> thread 1: >> for ((; ;)) >> { >> mount -t cgroup -o ns xxx cgroup/ > /dev/null 2>&1 >> # remove the dirs generated by cgroup_clone() >> rmdir cgroup/[1-9]* > /dev/null 2>&1 >> umount cgroup/ > /dev/null 2>&1 >> } >> >> >> thread 2: >> >> int foo(void *arg) >> { return 0; } >> >> char *stack[4096]; >> >> int main(int argc, char **argv) >> { >> int usec = DEFAULT_USEC; >> while (1) { >> usleep(usec); >> # cgroup_clone() will be called >> clone(foo, stack+4096, CLONE_NEWNS, NULL); >> } >> >> return 0; >> } > > Uh-oh... That clone() will do more, actually - it will clone a bunch > of vfsmounts. What happens if you create a separate namespace for the > first thread, so that the second one would not have our vfsmount to > play with? > The warning still can be triggered, but seems harder (cost me 1 hour) > Alternatively, what if the second thread is doing > mount --bind cgroup foo > umount foo > in a loop? > I ran following testcase, and triggered the warning in 1 hour: thread 1: for ((; ;)) { mount --bind /cgroup /mnt > /dev/null 2>&1 umount /mnt > /dev/null 2>&1 } tread 2: for ((; ;)) { mount -t cgroup -o cpu xxx /cgroup > /dev/null 2>&1 mkdir /cgroup/0 > /dev/null 2>&1 rmdir /cgroup/0 > /dev/null 2>&1 umount -l /cgroup > /dev/null 2>&1 } > Another one: does turning the umount in the first thread into umount -l > affect anything? > For this one, I ran the test for the whole night, but failed to hit the warning. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers