[Bug 7700] busybox init calls vfork() but does not immediately call exec(), probably causing downstream pain
bugzilla at busybox.net
bugzilla at busybox.net
Wed Dec 10 11:17:46 UTC 2014
https://bugs.busybox.net/show_bug.cgi?id=7700
--- Comment #1 from Denys Vlasenko <vda.linux at googlemail.com> 2014-12-10 11:17:45 UTC ---
(In reply to comment #0)
> The vfork() man page says that after a vfork(), the child needs to just call
> exec(), and nothing else. Don't write to stack variables (with the sole
> exception of your pid_t). Don't call any other functions. Don't even return
> from the current function. Just call exec(), and if that fails you can call
> _exit().
POSIX rules for vfork are very restrictive because various other Unixes
have restrictive vfork implementations and/or compilers which
do not understand that vfork + needs special treatment.
What init.c is doing after vfork is valid for Linux vfork implementation.
> Don't even return from the current function.
We do obey this, because doing that is almost guaranteed to smash the stack of
the parent.
> Don't call any other functions.
Not even a strlen()? Why?
Please point out which operation in init.c after vfork you consider
questionable.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the busybox-cvs
mailing list