Prepare /benchexec cgroup inside BenchExec containers for nested uses?

[PhilippWendler]

With cgroups v2, it is tricky to benchmark a tool that uses cgroups itself. If the main process of the benchmarked tool is the one that creates subcgroups, it works (this is the case for example in runexec -- runexec -- ..), but if we benchmark a tool that spawns subprocesses and those use cgroups (e.g., by calling runexec), it will not work because the inner runexec will not find an empty and usable cgroup. There are already tools that work like this, and people wanting to benchmark such tools with BenchExec.

The general solution for this is to treat the outer BenchExec container like any other container and prepare its cgroups like in other containers before starting the tool that wants to use cgroups. (In the example above the call chain would thus look like runexec - init.sh (setting up cgroups) - the benchmarked tool - runexec.) This works.

However, in theory BenchExec could do what init.sh does whenever it creates a cgroup for a container: instead of just creating the root cgroup, create two subcgroups named /init (name can be changed) and /benchexec and put the main process into /init. Then any BenchExec process that is used inside a BenchExec container will find and use the (empty) /benchexec cgroup. This should work, but it only solves the "BenchExec used by tool inside BenchExec" use case and not nestings with a different container solution in either place. So it is maybe questionable if we want to special-case this.

Furthermore, BenchExec already now creates up 3 cgroups in up to 2 nesting layers per run, and this would add 2 more cgroups and one more nesting depth. Not sure whether we will eventually hit any kernel levels for deep nestings of containers.