join the cgroup after the initial setup finished

[lifubang]

We should join the cgroup after the initial setup finished,
but before runc init clone new children processes. (#4427)

Because we should try our best to reduce the influence of
memory cgroup accounting from all runc init processes
before we start the container init process.

If we cherry pick this commit to release-1.1, it will eliminate
the impacts of memory accounting from ensure_clone_binary.

[kolyshkin]

This made me look into why initWaiter is added, and here's what I found:

• added by commit 4ecff8d (see its description as for why);
• since commit 0e9a335 it might no longer be necessary to have initWaiter at all.

So I opened a draft PR to remove it (#4441).

[kolyshkin]

Frankly, I don't understand what this PR is doing, or what difference does it make, from looking in the main branch code.

[lifubang]

Frankly, I don't understand what this PR is doing, or what difference does it make, from looking in the main branch code.

There is really a race situation here, it's very obviously in the branch release-1.1. (containerd/containerd#10799 (comment))
Yes, this is not very important after we have moved the binary clone operation from runc init to runc create/run, but it also have a unimportant race here. If we keep this initWaiter, it will let runc in A stable state rather than a race state.

[lifubang]

Like I mentioned in #4439 (comment)
If we removed this initWaiter, the cgroup resource accounting before nl_parse(pipenum, &config) in runc init maybe lost when we are joining the cgroup.

runc/libcontainer/nsenter/nsexec.c

Line 896 in ea5f8e0

nl_parse(pipenum, &config);

[lifubang]

I don't understand what this PR is doing,

I think the waitInit chan waiting's place is wrong, it will also cause this unimportant race situation mentioned above, so I place it in the correct place. This is what this PR doing.
And I have test it, it will not introduce any performance issue in the main branch.

[lifubang]

The other aspect, keep this initWaiter also may be useful for future, for example, maybe for some times in future, we need to add some expensive function call like ensure_clone_binary in nsexec.

[kolyshkin]

Yes, I can understand why this is needed in 1.1.

I still can not understand why this is needed here in the main branch, what race it is fixing, what difference does it make.

Can you please explain the race in details to me? Like, draw two columns, one for runc parent, another for runc init, and write which one is doing what and how a race can happen.

Or, I will take another look next week (maybe I'm just dumb and tired).

The other aspect, keep this initWaiter also may be useful for future, for example, maybe for some times in future, we need to add some expensive function call like ensure_clone_binary in nsexec.

This is not a good argument. First of all, we hope we'll have less code in nsexec, not more, and in general, the less locking and synchronization there is, the better.