From owner-freebsd-bugs  Tue Apr 17  1:40: 6 2001
Delivered-To: freebsd-bugs@hub.freebsd.org
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id EF6F937B424
	for <freebsd-bugs@hub.freebsd.org>; Tue, 17 Apr 2001 01:40:00 -0700 (PDT)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f3H8e0v83205;
	Tue, 17 Apr 2001 01:40:00 -0700 (PDT)
	(envelope-from gnats)
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
X-Send-Pr-Version: www-1.0
Subject: kern/26638: kern.fast_vfork sysctl doesn't do anything & maybe should?
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>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:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 17 01:40:00 PDT 2001
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message