suggestion for improvement to vfork() man page

suggestion for improvement to vfork() man page

[starlight-Utvwg/EOxnhfq8cQ1yknNg]

Also I don't think it is unfortunate (or a bug)
that vfork() continues to exist in Linux aside
from the fact that the semantics differ from
other *nixes in subtle and potentially
confusing ways.

As implemented in Linux vfork() is quite useful
and with the aforementioned clarifications to
the documentation, worth retaining.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 709 bytes --]

On Wednesday 18 January 2012 22:16:28 starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org wrote:
> Also I don't think it is unfortunate (or a bug)
> that vfork() continues to exist in Linux aside
> from the fact that the semantics differ from
> other *nixes in subtle and potentially
> confusing ways.
> 
> As implemented in Linux vfork() is quite useful
> and with the aforementioned clarifications to
> the documentation, worth retaining.

it also most likely won't ever be going away.  a few reasons:
	- vfork() is really just a clone() with certain flags
	- clone() is never going away as it is used to create threads
	- vfork() is required for no-mmu systems (can't implement fork())
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: suggestion for improvement to vfork() man page

[Michael Kerrisk]

Hi,

On Fri, Jan 20, 2012 at 7:36 AM, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
> On Wednesday 18 January 2012 22:16:28 starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org wrote:
>> Also I don't think it is unfortunate (or a bug)
>> that vfork() continues to exist in Linux aside
>> from the fact that the semantics differ from
>> other *nixes in subtle and potentially
>> confusing ways.
>>
>> As implemented in Linux vfork() is quite useful
>> and with the aforementioned clarifications to
>> the documentation, worth retaining.

Agreed. I inherited that text in the man page, but it never irritated
me quite *enough* to remove it. But all I needed was a little push.

> it also most likely won't ever be going away.  a few reasons:
>        - vfork() is really just a clone() with certain flags
>        - clone() is never going away as it is used to create threads
>        - vfork() is required for no-mmu systems (can't implement fork())
> -mike

Thanks for those notes also Mike.

I've applied the patch below:

=====
--- a/man2/vfork.2
+++ b/man2/vfork.2
@@ -169,6 +169,40 @@ remaining blocked until the child either
terminates or calls
 and cannot rely on any specific behavior with respect to shared memory.
 .\" In AIXv3.1 vfork is equivalent to fork.
 .SH NOTES
+.PP
+Some consider the semantics of
+.BR vfork ()
+to be an architectural blemish, and the 4.2BSD man page stated:
+"This system call will be eliminated when proper system sharing mechanisms
+are implemented.
+Users should not depend on the memory sharing semantics of
+.BR vfork ()
+as it will, in that case, be made synonymous to
+.BR fork (2).\c
+"
+However, even though modern memory management hardware
+has decreased the performance difference between
+.BR fork ()
+and
+.BR vfork (2),
+there are various reasons why Linux and other systems have retained
+.BR vfork ():
+.IP * 3
+Some performance-critical applications require the small performance
+advantage conferred by
+.BR vfork ().
+.IP *
+.BR vfork (2)
+can be implemented on systems that lack a memory-management unit
+(typically, embedded systems), but
+.BR fork (2)
+can't be implemented on such systems.
+(However, on such systems,
+the preferred standard way of accomplishing the same result is to use
+.BR posix_spawn (3).)
+.\" http://stackoverflow.com/questions/4259629/what-is-the-difference-between-fork-and-vfork
+.\" http://developers.sun.com/solaris/articles/subprocess/subprocess.html
+.\" http://mailman.uclinux.org/pipermail/uclinux-dev/2009-April/000684.html
 .SS Linux Notes
 Fork handlers established using
 .BR pthread_atfork (3)
@@ -208,16 +242,7 @@ Since 2.2.0-pre9 (on i386, somewhat later on
 other architectures) it is an independent system call.
 Support was added in glibc 2.0.112.
 .SH BUGS
-It is rather unfortunate that Linux revived this specter from the past.
-The BSD man page states:
-"This system call will be eliminated when proper system sharing mechanisms
-are implemented.
-Users should not depend on the memory sharing semantics of
-.BR vfork ()
-as it will, in that case, be made synonymous to
-.BR fork (2).\c
-"

Re: suggestion for improvement to vfork() man page

[starlight-Utvwg/EOxnhfq8cQ1yknNg]

+(However, on such systems,
+the preferred standard way of accomplishing the same result is to use
+.BR posix_spawn (3).)

I'm not sure I agree on this.  Linux posix_spawn()
calls fork() which for us is undesirable on MMU systems
due to the cost of copying large page tables.

To the extent that we would add support for non-MMU
platforms, we would stick with direct invocation of
vfork() even if the posix_spawn() on those targets
used vfork() instead of fork().  One less #ifdef,
of which we have far too many as it is.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[Michael Kerrisk]

Hi,

On Wed, Feb 8, 2012 at 10:50 AM,  <starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org> wrote:
> +(However, on such systems,
> +the preferred standard way of accomplishing the same result is to use
> +.BR posix_spawn (3).)
>
> I'm not sure I agree on this.  Linux posix_spawn()
> calls fork()

I think isn't quite correct. I believe glibc's posix_spawn uses
vfork() where it can. See sysdeps/posix/spawni.c::spawni().

> which for us is undesirable on MMU systems
> due to the cost of copying large page tables.
>
> To the extent that we would add support for non-MMU
> platforms, we would stick with direct invocation of
> vfork() even if the posix_spawn() on those targets
> used vfork() instead of fork().  One less #ifdef,
> of which we have far too many as it is.

So, I'll change that last sentence to

[[
(POSIX.1-2008 removed vfork() from the standard; the POSIX rationale
for  the posix_spawn(3) function notes that that function, which
provides functionality equivalent to fork(2)+exec(3) is designed to be
implementable on systems that lack an MMU.)
]]

What do you think?

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[Eric Wong]

starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org wrote:
> +(However, on such systems,
> +the preferred standard way of accomplishing the same result is to use
> +.BR posix_spawn (3).)
> 
> I'm not sure I agree on this.  Linux posix_spawn()
> calls fork() which for us is undesirable on MMU systems
> due to the cost of copying large page tables.

posix_spawn() under glibc will try to automatically use vfork() instead
of fork() in some cases.  There is also a GNU-specific
POSIX_SPAWN_USEVFORK flag to force vfork() usage, too.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[starlight-Utvwg/EOxnhfq8cQ1yknNg]

At 12:04 PM 2/8/2012 +1300, Michael Kerrisk wrote:
>Hi,
>
>On Wed, Feb 8, 2012 at 10:50 AM,  <starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org> wrote:
>> +(However, on such systems,
>> +the preferred standard way of accomplishing the same result is to use
>> +.BR posix_spawn (3).)
>>
>> I'm not sure I agree on this.  Linux posix_spawn()
>> calls fork()
>
>I think isn't quite correct. I believe glibc's posix_spawn uses
>vfork() where it can. See sysdeps/posix/spawni.c::spawni().

Looked at glibc-2.9 and posix_spawn() uses
fork() in only when no process attibutes are
modified (i.e. it respects the AIX and Solaris
semantics of vfork though this is a bit irrelevent
since AIX and Solaris have kernel-native support
for posix_spawn) or when a non-standard
POSIX_SPAWN_USEVFORK flag is present.  It's
rather muddy so I stick with #ifdef vfork()
for Linux and #ifdef posix_spawn() for the
*nixes.

>
>So, I'll change that last sentence to
>
>[[
>(POSIX.1-2008 removed vfork() from the standard; the POSIX rationale
>for  the posix_spawn(3) function notes that that function, which
>provides functionality equivalent to fork(2)+exec(3) is designed 
>to be implementable on systems that lack an MMU.)
>]]
>
>What do you think?

That's fair.  Perhaps the posix_spawn() page should
have some text regarding the conditional use of vfork()
under the covers.  I seen no mention of vfork() on
the die.net page, and can't find it on kernel.org.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

suggestion for improvement to vfork() man page

[starlight-Utvwg/EOxnhfq8cQ1yknNg]

Hello,

Please consider the following two suggestions for
adjusting the vfork() man page.

In the "Linux Description" section it should be
mentioned that vfork() does not suspend all the
threads in the parent process and only suspends
the thread issuing the call to vfork().  The
wording is misleading and I misunderstood the
semantics for a long time, thinking that all
threads would be suspended.  Had to test it to
determine the actual effect for certain.  In our
case suspending all threads for even a few
microseconds is unacceptable.

Also, it is important to note that the
clone(CLONE_VFORK|CLONE_VM) call invoked by
vfork() makes a separate copy of all process
resources except the address space.  While this is
implied by the statement "the vfork() function has
the same effect as fork(2)," this is easily
overlooked by someone who works with various UNIXs
where this is most definitely not the case.

This matters for situations like ours where a
process with a huge address space, real-time
priority and root privileges must occasionally
spawn scripts that should run at user priority
with user privileges.  Using fork() is expensive
due to the cost of replicating very large page
tables and vfork() is an excellent alternative.
But the subtle difference between Solaris/AIX and
Linux caused us to unnecessarily disable the code
that lowers priority and surrenders root
permission before issuing the exec() call to run
scripts.

Regards

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[Michael Kerrisk]

Hi,

On Thu, Jan 19, 2012 at 4:04 PM,  <starlight-Utvwg/EOxnhfq8cQ1yknNg@public.gmane.org> wrote:
> Hello,
>
> Please consider the following two suggestions for
> adjusting the vfork() man page.
>
> In the "Linux Description" section it should be
> mentioned that vfork() does not suspend all the
> threads in the parent process and only suspends
> the thread issuing the call to vfork().  The
> wording is misleading and I misunderstood the
> semantics for a long time, thinking that all
> threads would be suspended.  Had to test it to
> determine the actual effect for certain.  In our
> case suspending all threads for even a few
> microseconds is unacceptable.

Good point. For 3.36, I made the following change.

=====
--- a/man2/vfork.2
+++ b/man2/vfork.2
@@ -97,7 +97,7 @@ where a child is created which then immediately issues an
 .BR vfork ()
 differs from
 .BR fork (2)
-in that the parent is suspended until the child terminates
+in that the calling thread is suspended until the child terminates
 (either normally,
 by calling
 .BR _exit (2),
=====

> Also, it is important to note that the
> clone(CLONE_VFORK|CLONE_VM) call invoked by
> vfork() makes a separate copy of all process
> resources except the address space.  While this is
> implied by the statement "the vfork() function has
> the same effect as fork(2)," this is easily
> overlooked by someone who works with various UNIXs
> where this is most definitely not the case.

I'm just curious here...  The most pertinent case I can think of here
is file descriptors, which *are* duplicated on all vfork()
implementations that I've come across. When you say "UNIXs where this
is most definitely not the case", what (process attributes) are you
thinking of.

> This matters for situations like ours where a
> process with a huge address space, real-time
> priority and root privileges must occasionally
> spawn scripts that should run at user priority
> with user privileges.  Using fork() is expensive
> due to the cost of replicating very large page
> tables and vfork() is an excellent alternative.
> But the subtle difference between Solaris/AIX and
> Linux caused us to unnecessarily disable the code
> that lowers priority and surrenders root
> permission before issuing the exec() call to run
> scripts.

Yes, a few words on those lines does not hurt. I made the following change:

=====
--- a/man2/vfork.2
+++ b/man2/vfork.2
@@ -110,9 +110,19 @@ The child must not return from the current function or call
 .BR exit (3),
 but may call
 .BR _exit (2).
-.PP
-Signal handlers are inherited, but not shared.
-Signals to the parent
+
+As with
+.BR fork (2),
+the child process created by
+.BR vfork ()
+inherits copies of various of the caller's process attributes
+(e.g., file descriptors, signal dispositions, and current working directory);
+the
+.BR vfork ()
+call differs only in the treatment of the virtual address space,
+as described above.
+
+Signals sent to the parent
 arrive after the child releases the parent's memory
 (i.e., after the child terminates
 or calls
=====

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for improvement to vfork() man page

[starlight-Utvwg/EOxnhfq8cQ1yknNg]

Looks good.  Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html