--NextPart-20060928205701-1583100
Content-Type: Text/Plain; charset=us-ascii

> Ah, thanks for pointing this out.  With this in mind, I've tested even
> more and determined that the vnode never gets on the VONWORKLST or has
> a VM_PROT_WRITE getpages call at all.  I'm now thinking that the page
> gets mapped writable for the purposes of reading in its original data,
> and never gets write protected.  Since its never gets VONWORKLST at
> all, subsequent putpages calls don't write protect it (cleanall == 0)

UVM_OBJ_NEEDS_WRITEFAULT is for it.
ah, ubc_fault seems missing the check.  it's a bug.
the attached patch should fix it. (not tested)

> I will continue to investigate how the pages are getting mapped
> writable and will send more information tomorrow.

PR/33513 can be related as well.

YAMAMOTO Takashi

--NextPart-20060928205701-1583100
Content-Type: Text/Plain; charset=us-ascii
Content-Disposition: attachment; filename="a.diff"

Index: uvm_bio.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_bio.c,v
retrieving revision 1.48
diff -u -p -r1.48 uvm_bio.c
--- uvm_bio.c	3 Sep 2006 21:33:33 -0000	1.48
+++ uvm_bio.c	28 Sep 2006 11:56:17 -0000
@@ -42,6 +42,7 @@ __KERNEL_RCSID(0, "$NetBSD$");
 #include <sys/systm.h>
 #include <sys/malloc.h>
 #include <sys/kernel.h>
+#include <sys/vnode.h>
 
 #include <uvm/uvm.h>
 
@@ -356,8 +370,9 @@ again:
 		 * is marked as PG_RDONLY.
 		 */
 
-		rdonly = (access_type & VM_PROT_WRITE) == 0 &&
-		    (pg->flags & PG_RDONLY) != 0;
+		rdonly = ((access_type & VM_PROT_WRITE) == 0 &&
+		    (pg->flags & PG_RDONLY) != 0) ||
+		    UVM_OBJ_NEEDS_WRITEFAULT(uobj);
 		KASSERT((pg->flags & PG_RDONLY) == 0 ||
 		    (access_type & VM_PROT_WRITE) == 0 ||
 		    pg->offset < umap->writeoff ||

--NextPart-20060928205701-1583100--