From nobody@FreeBSD.org  Tue Apr 17 01:30:23 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 8E05237B43E
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 17 Apr 2001 01:30:23 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f3H8UNs81522;
	Tue, 17 Apr 2001 01:30:23 -0700 (PDT)
	(envelope-from nobody)
Message-Id: <200104170830.f3H8UNs81522@freefall.freebsd.org>
Date: Tue, 17 Apr 2001 01:30:23 -0700 (PDT)
From: matt@braithwaite.net
To: freebsd-gnats-submit@FreeBSD.org
Subject: kern.fast_vfork sysctl doesn't do anything & maybe should?
X-Send-Pr-Version: www-1.0

>Number:         26638
>Category:       kern
>Synopsis:       kern.fast_vfork sysctl doesn't do anything & maybe should?
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 17 01:40:00 PDT 2001
>Closed-Date:    Sun Feb 3 19:31:12 PST 2002
>Last-Modified:  Sun Feb 03 19:31:37 PST 2002
>Originator:     Matthew Braithwaite
>Release:        4.2-RELEASE
>Organization:
>Environment:
>Description:
This sysctl used to control whether vfork(2) passes the RFMEM flag to fork1 (see sys/kern/kern_fork.c:vfork).  This behavior was removed in kern_fork.c:1.62, but the sysctl remains, and nothing uses the fast_vfork variable any more.

I do not understand the commit message for 1.62, not being a kernel hacker, but it does not obviously say to me that this was a deliberate change.  

I'll expose my ignorance further by guessing that what `fast_vfork' means is `don't implement copy-on-write behavior for the process's memory during a vfork, so that the child is able to modify the memory that the parent will see when it's reawakened.'  I am supported in this guess by the fact that restoring the old behavior, and turning fast_vfork off, fixes some problems I was having using vfork (directly, via syscall()) in Perl.

So, my ignorant opinion is that the old behavior, removed in 1.62, should be restored, since this sysctl is handy.  If it can't be restored, then it seems to me that it should be removed, or at least made readonly, to correspond with reality.
>How-To-Repeat:

>Fix:
*** kern_fork.c~        Mon Nov 27 18:33:32 2000
--- kern_fork.c Tue Apr 17 01:27:02 2001
***************
*** 114,120 ****
        int error;
        struct proc *p2;
  
!       error = fork1(p, RFFDG | RFPROC | RFPPWAIT | RFMEM, &p2);
        if (error == 0) {
                p->p_retval[0] = p2->p_pid;
                p->p_retval[1] = 0;
--- 114,120 ----
        int error;
        struct proc *p2;
  
!       error = fork1(p, RFFDG | RFPROC | RFPPWAIT | (fast_vfork ? RFMEM : 0), &p2);
        if (error == 0) {
                p->p_retval[0] = p2->p_pid;
                p->p_retval[1] = 0;

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: silby 
State-Changed-When: Sun Feb 3 19:31:12 PST 2002 
State-Changed-Why:  
fast_vfork + the sysctl have been removed. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26638 
>Unformatted:
