[Bug libc/26371] [RFE] please add clone3() wrapper (in particular the CLONE_INTO_CGROUP feature of it)

["mztyvop at 0pointer dot net" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26371

--- Comment #4 from Lennart Poettering <mztyvop at 0pointer dot net> ---
(I'd not be totally opposed to the vfork()-style stuff btw. In some cases the
child might stick around for quite a while between the clone and the execve,
because of blocking NSS or other blocking stuff, as mentioned. It's a bit of a
cow-trap due to that in particular as during boot-up we fork off a lot of these
children very quickly. I hence wondered whether to rework the logic in systemd:
instead of doing the whole shebang of service setup before execve() in the
child, maybe we should insert another binary in between, i.e. an "executor"
program that receives what it is supposed to do in JSON serialized form or so,
then does NSS and whatnot, and then finally execve()'s the final program. In
that model, we'd fork off a child and then have two execve()'s before the final
program is executed, and the "middle" program would be responsible for all the
blocking stuff. In this model having vfork() would be fine I guess (or even
posix_spawn()) given that we'd spend much less time between the vfork() and the
first execve(), and definitely nothing doing blocking IO. That all said, I am
not sure whether such a design change would actually slow us down too much,
i.e. doing two execve()'s for each invoked user binary instead of one might be
more expensive than the cow trap, dunno. So far I was too lazy to do any
peformance analysis there)

-- 
You are receiving this mail because:
You are on the CC list for the bug.