On Wed, May 13, 2020 at 11:40:15AM -0400, Jan Stancek wrote: > In LTP issue above it was clear that memory controller is in use. > Here it looks like some lingering reference to cpuset controller > that can't be seen in sysfs. > > It's triggered by podman tests actually: > 1. run podman tests > 2. mount -t cgroup -ocpuset cpuset /mnt/cpuset/ -> EBUSY > > # mount | grep cgroup > cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel) > > # grep cpuset -r /sys/fs/cgroup/ > /sys/fs/cgroup/cgroup.controllers:cpuset cpu io memory pids > > And yet, v1 cgroup fails to mount: > > # mount -t cgroup -ocpuset cpuset /mnt/cpuset/ > mount: /mnt/cpuset: cpuset already mounted or mount point busy. While if a regression it may point to a newly introduced behavior, in general, dynamically reassigning cgroup controllers to a different version hierarchy after active use is not something fully supported. From cgroup2 documentation: A controller can be moved across hierarchies only after the controller is no longer referenced in its current hierarchy. Because per-cgroup controller states are destroyed asynchronously and controllers may have lingering references, a controller may not show up immediately on the v2 hierarchy after the final umount of the previous hierarchy. Similarly, a controller should be fully disabled to be moved out of the unified hierarchy and it may take some time for the disabled controller to become available for other hierarchies; furthermore, due to inter-controller dependencies, other controllers may need to be disabled too. While useful for development and manual configurations, moving controllers dynamically between the v2 and other hierarchies is strongly discouraged for production use. It is recommended to decide the hierarchies and controller associations before starting using the controllers after system boot. Thanks. -- tejun
