You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running --security-opt unmask=/sys/fs/cgroup exposes it rw is an obvious workaround, but if it can't work around pre-runtime setup of the container, is it acceptable to not make it RO?
If the cpu/memory/device command line options impose limits maybe the mounted cgroup needs to be a submount from there to enforce those limits?
Additional context
/sys/fs/cgroup was originally added as a ro bind mount - cf36470. Because rbind exposed host info this became a fresh mount (8d3010d). Because this is a fresh mount of a cgroup, the information pertains to the current container and should be writeable (as the permissions on the /sys/fs/cgroup/ files indicate)?
Negative case:
There are a number of cpu/memory/device cgroupv2 limits exposed on the command line and a rw mount might make these able to be exceeded by a container.
The text was updated successfully, but these errors were encountered:
A container could create a lot of sub-cgroups, potentially slowing down the kernel. So for the default case, I think it is still safer to mount it read-only and tweak it only when necessary
Feature request description
PSI, pressure stall information, of the kernel should be available to user containers by default.
Suggest potential solution
cgroupv2 as rw by default.
Have you considered any alternatives?
Running
--security-opt unmask=/sys/fs/cgroup
exposes itrw
is an obvious workaround, but if it can't work around pre-runtime setup of the container, is it acceptable to not make it RO?If the cpu/memory/device command line options impose limits maybe the mounted cgroup needs to be a submount from there to enforce those limits?
Additional context
/sys/fs/cgroup was originally added as a ro bind mount - cf36470. Because rbind exposed host info this became a fresh mount (8d3010d). Because this is a fresh mount of a cgroup, the information pertains to the current container and should be writeable (as the permissions on the /sys/fs/cgroup/ files indicate)?
Negative case:
There are a number of cpu/memory/device cgroupv2 limits exposed on the command line and a rw mount might make these able to be exceeded by a container.
The text was updated successfully, but these errors were encountered: