Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 12 Apr 2008 15:33:53 -0700
From:      "Kip Macy" <kip.macy@gmail.com>
To:        "Matthew Dillon" <dillon@apollo.backplane.com>
Cc:        hackers@freebsd.org, Jonathan Chen <jon@freebsd.org>
Subject:   Re: mlock & COW
Message-ID:  <b1fa29170804121533q792b6491u106794ce722e78e3@mail.gmail.com>
In-Reply-To: <200804122156.m3CLuot5065753@apollo.backplane.com>
References:  <20080309212441.GA56523@porthos.spock.org> <200804122156.m3CLuot5065753@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 12, 2008 at 2:56 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>     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.


For TCP offload I just have to ensure that the users pages have the
right permissions and don't get re-allocated during DMA so I have the
following fairly simple code:

http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/cxgb/ulp/tom/cxgb_vm.c?rev=1.1;content-type=text%2Fplain

The one bit that is interesting is that on receive I know in advance
that I will be writing to the pages so I force the COW fault in
advance before holding the page.

This doesn't address the issue of mlock and cow in the general case,
but its a good example of how knowing your application can greatly
simplify the code.

 -Kip



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170804121533q792b6491u106794ce722e78e3>