Messages in this thread | | | Date | Fri, 13 Feb 2009 13:09:17 +0800 | From | Li Zefan <> | Subject | Re: [cgroup or VFS ?] WARNING: at fs/namespace.c:636 mntput_no_expire+0xac/0xf2() |
| |
>> 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.
| |