* Issue with mount options on mount/umount
@ 2016-03-14 14:22 Stanislav Kholmanskikh
0 siblings, 0 replies; only message in thread
From: Stanislav Kholmanskikh @ 2016-03-14 14:22 UTC (permalink / raw)
To: cgroups-u79uwXL29TY76Z2rM5mHXA, tj-DgEjT+Ai2ygdnm+yROfE0A,
hannes-druUgvl0LCNAfugRpC6u6w, lizefan-hv44wF8Li93QT0dZR+AlfA
Cc: Vasily Isaenko
Hello!
It seems that if 'umount' happens before some cgroup cleanup processes
finish, we will not be able to mount this cgroup with changed options.
For example, consider this test case (where I'm playing with noprefix):
#!/bin/sh
mkdir /tmp/bla
mkdir /dev/cgroup
mount -t cgroup -o cpuset,noprefix bla /dev/cgroup
mkdir /dev/cgroup/ltp
rmdir /dev/cgroup/ltp
#sleep 1
umount /dev/cgroup
rmdir /dev/cgroup
for i in $(seq 2); do
echo $i
echo $i > /dev/kmsg
mount -t cgroup -o cpuset bla /tmp/bla; ls /tmp/bla | grep
effective_cpus; umount /tmp/bla
done
rmdir /tmp/bla
If it's executed as is, it reports:
[root@ol6-x64 cgroup]# ./test.sh
1
effective_cpus
2
cpuset.effective_cpus
and in dmesg:
[root@ol6-x64 cgroup]# dmesg|tail
1
cgroup: new mount options do not match the existing superblock, will be
ignored
2
If we uncomment that 'sleep 1' the test will report
cpuset.effective_cpus for both the iterations.
The kernel is v4.5-rc7-159-g7f02bf6. However, this issue is applicable
to older versions as well.
Is this behavior a bug or feature? If it's a feature, then what is the
motivation for this behavior?
Thank you.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2016-03-14 14:22 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-14 14:22 Issue with mount options on mount/umount Stanislav Kholmanskikh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).