On 10/27/20 12:26 PM, Michal Koutný wrote:
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.
Oops. My wording was overly dramatic. My in-house customers
get nervous when things differ within a container vs. on a host.
You're right, it differs, but that's an acceptable side effect
of the improved design of cgroup v2.
Would you mind sharing some of the other discrepancies? I
would like to be prepared when we run into them as well.
Thanks!
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.
Good call. I didn't think of that.
* 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.
That makes a lot of sense. I think I will need to spend
time with the database team and others. Cgroup v2 is simply
different enough that we'll need to rethink some of the
decisions that were made for cgroup v1.
Thanks so much for the help.
Tom
Michal
