Re: [RFC][PATCH] exec: Freeze the other threads during a multi-threaded exec
From: Eric W. Biederman
Date: Tue Jul 28 2020 - 08:21:50 EST
Aleksa Sarai <cyphar@xxxxxxxxxx> writes:
> On 2020-07-27, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>> To the best of my knowledge processes with more than one thread
>> calling exec are not common, and as all of the threads will be killed
>> by exec there does not appear to be any useful work a thread can
>> reliably do during exec.
> Every Go program which calls exec (this includes runc, Docker, LXD,
> Kubernetes, et al) fills the niche of "multi-threaded program that calls
> exec" -- all Go programs are multi-threaded and there's no way of
> disabling this. This will most likely cause pretty bad performance
> regression for basically all container workloads.
So it is a good point that container runtimes use Go, and that
fundamentally anything that uses Go will be multi-threaded. Having just
looked closely at this I don't think in practice this is an issue even
at this early state of my code.
If those other threads are sleeping the code I have implemented should
be a no-op.
If those threads aren't sleeping you have undefined behavior, as at
some point the kernel will come through and kill those threads.
Further unless I am completely mistaken the container runtimes use
forkAndExecInChild from go/src/syscall/exec_linux.go which performs a
vfork before performing the exec.