From owner-freebsd-hackers@FreeBSD.ORG  Sat Apr 12 21:56:51 2008
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 61FF2106566C;
	Sat, 12 Apr 2008 21:56:51 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.freebsd.org (Postfix) with ESMTP id 2A68C8FC1D;
	Sat, 12 Apr 2008 21:56:51 +0000 (UTC)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m3CLuodT065754;
	Sat, 12 Apr 2008 14:56:50 -0700 (PDT)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.14.1/8.13.4/Submit) id m3CLuot5065753;
	Sat, 12 Apr 2008 14:56:50 -0700 (PDT)
Date: Sat, 12 Apr 2008 14:56:50 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200804122156.m3CLuot5065753@apollo.backplane.com>
To: Jonathan Chen <jon@freebsd.org>
References: <20080309212441.GA56523@porthos.spock.org>
Cc: hackers@freebsd.org
Subject: Re: mlock & COW
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Apr 2008 21:56:51 -0000

    I've looked at it some more and it looks like it would be a real
    mess to do it in the protection code.  I think it may be best to
    fix it in the fault code.  That is, to explicitly allow a user-wired
    page to be write-faulted.

    The primary protection check that is causing the segv is in 
    vm_map_lookup() line 3161 and line 3297 (FreeBSD current).  Commenting
    those out will allow the COW on the user-wired page:

        if ((entry->eflags & MAP_ENTRY_USER_WIRED) &&
            (entry->eflags & MAP_ENTRY_COW) &&
            (fault_type & VM_PROT_WRITE) &&
            (fault_typea & VM_PROT_OVERRIDE_WRITE) == 0) {
                RETURN(KERN_PROTECTION_FAILURE);
        }

    BUT!  This is going to cause a panic later on.  There is one big gotcha
    and that is the COW fault will cause the VM system to lose track of
    the wiring of (I think) either the original page or the COW'd page,
    and you will get a panic when it tries to unwire it later on.

    I will mess with it a bit in DragonFly to see if there's a simple
    solution.

					-Matt