Hi Tom. On Tue, Oct 20, 2020 at 03:12:28PM -0600, Tom Hromatka <tom.hromatka@xxxxxxxxxx> wrote: > But this fails on a cgroup v2 system in a > cgroup namespace because the root cgroup is a non-leaf cgroup. Yes, the no internal process constraint simplifies and enables many things for v2 controllers. > * As outlined above, the behavior of the "root" cgroup in a cgroup > namespace on a v2 system differs from the behavior of the > unnamespaced root cgroup. At best this is inconsistent; at worst, > this may leak information to an unethical program. What information does this leak? (That it's running in a cgroup namespace?) Note that this isn't the only discrepancy between host root cgroup and namespaced root cgroup. The host group is simply special. > Any ideas how we can make the behavior more consistent for the > user and libcgroup? You can disable the controllers (via parent's cgroup.subtree_control) to allow migration into the parent. Of course that affects also siblings of the removed cgroup. > * I will likely add a flag to cgdelete to simply kill processes in > a cgroup rather than try and move them to the parent cgroup. > Moving processes to the parent cgroup is somewhat challenging > even in a cgroup v1 system due to permissions, etc. In general, migrations with controlled v2 cgroup are not supported, so moving processes up and (especially) down has less sense than in v1. Hence, refusing the delete operation on a populated cgroup (with controllers) is IMO justified. Michal
Attachment:
signature.asc
Description: Digital signature
