| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Oct 2011 11:02:38 +0800 From: Li Zefan <lizf@...fujitsu.com> To: handai handai <handai.szj@...il.com> CC: linux-kernel@...r.kernel.org Subject: Re: [Fwd: Re: cgroup umount bug] >> I'm not sure from what you write whether you're aware of this, but >> to work around this, you can then >> >> mount -t cgroup -o cpu /mnt >> for i in `cat /mnt/test/tasks`; do >> echo $i > /mnt/tasks >> done >> rmdir /mnt/test >> umount /mnt >> >> and now you can >> >> mount -cgroup -o cpu,cpuset cgroup /mnt >> > > I know that I can bypass this problem by deleting subgroups before > unmount. But there is no document mentioning that I should do this to > avoid it. But even if there is, users may still directly umount it > accidentally, then he should try to remember what he has done and back > to the scene to make it up, or he may need to reboot his server to do > another test : ( . You can check /proc/cgroups: # mount -t cgroup -o cpu,cpuset cgroup /mnt # mkdir /mnt/sub # umount /mnt # cat /proc/cgroups #subsys_name hierarchy num_cgroups enabled cpuset 1 2 1 cpu 1 2 1 memory 0 1 1 devices 0 1 1 freezer 0 1 1 net_cls 0 1 1 blkio 0 1 1 > So, since there is nothing good to permit incompletely unmount, why > not prevent the potential problem by prohibiting this behavior at > first ? > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists