On Tue, Apr 30, 2019 at 5:39 AM Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>
> Yes, but I am wondering if man vfork should clarify what "child terminates"
> actually means. I mean, the child can do clone(CLONE_THREAD) + sys_exit(),
> this will wake the parent thread up before the child process exits or execs.
That falls solidly into the "give people rope" category.
If the vfork() child wants to mess with the parent, it has many easier
ways to do it than create more threads.
As mentioned, the real problem with vfork() tends to be that the child
unintentionally messes with the parent because it just gets the stack
sharing wrong. No need to add intention there.
> I see nothing wrong, but I was always curious whether it was designed this
> way on purpose or not.
Oh, it's definitely on purpose. Trying to do some nested usage count
would be horrendously complex, and even a trivial "don't allow any
other clone() calls if we already have a vfork completion pending" is
just unnecessary logic.
Because at least in *theory*, there's actually nothing horribly wrong
with allowing a thread to be created during the vfork(). I don't see
the _point_, but it's not conceptually something that couldn't work
(you'd need a separate thread stack etc, but that's normal clone()).
So no, there's no safety or bogus "you can't do that". If you want to
play games after vfork(), go wild.
Linus
