Add a lock around cgroupd communication.

[hanwen-flow]

Threads are put into cgroups through the cgroupd thread, which communicates with other threads using a socketpair. Each thread received a dup'd copy of the socket, and did the following

sendmsg(socket_dup_fd, my_cgroup_set);

// wait for ack.
while (1) {
    recvmsg(socket_dup_fd, &h, MSG_PEEK);
    if (h.pid != my_pid) continue;
    recvmsg(socket_dup_fd, &h, 0);
}
close(socket_dup_fd);

When restoring many threads, most threads would be spinning in the above loop waiting for their PID to appear.

In my test-case, restoring a process with a 11.5G heap and 491 threads could take anywhere between 10 seconds and 60 seconds to complete.

To avoid the spinning, we drop the loop and MSG_PEEK, and add a lock around the above code. This does not decrease parallelism, as the cgroupd daemon uses a single thread anyway.

With the lock in place, the same restore takes a consistent 9.2 seconds on my machine (Thinkpad P14s, AMD Ryzen 8840HS).

There is a similar "daemon" thread for user namespaces. That already is protected with a similar userns_sync_lock in __userns_call().

Fixes #2614

[hanwen-flow]

PTAL

[minhbq-99]

There are 3 empty lines which have the tabs at the beginning so the linter is complaining.

I think the commit title should be "restorer: Add a lock around cgroupd communication" to follow the project's convention.

These are nits. Overall, the approach LGTM.

[hanwen-flow]

thanks, PTAL.

I tried running 'make lint', but it wants to run 'ruff' which isn't available on Ubuntu 24.

[rst0git]

it wants to run 'ruff' which isn't available on Ubuntu 24.

Have you tried pip3 install ruff?

[avagin]

Merged. Thanks a lot.