On Sat, Apr 12, 2008 at 2:56 PM, Matthew Dillon
<[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
