This is a multipart MIME message.

--==_Exmh_21096844084680
Content-Type: text/plain; charset=us-ascii


chuq@chuq.com said:
> think of access_type as the logical type of VM access, not the
> particular type of trap that was taken

OK, with that in mind things make sense. It is not that obvious
if one just looks at the code, because the access_type is
mostly passed through from the md trap handler via uvm to fs.

> the use of VM_PROT_* to refer to types of VM access as well as
> permissions is ubiquitous

Yes, and I agree that this is better than remapping flags
here and there.

while we are here: While I had the bounds check at the beginning
of genfs_getpages instrumented to track down the prefetch thing,
I noticed that the read-ahead code frequently issues reads behind
EOF. This causes a pointless recursion through the fs back to
genfs_getpages which should be avoided.
As I see it there is no check whether
raoffset = startoffset + totalbytes
is not already at/past EOF from the beginning, nor whether
raoffset + N*rasize
hits EOF eventually.
I've tried the appended patch successfully. It would certainly
make sense to clip the ra requests instead if skipping.
Where does the magic "16" come from?

best regards
Matthias



--==_Exmh_21096844084680
Content-Type: text/plain ; name="rachk.txt"; charset=us-ascii
Content-Description: rachk.txt
Content-Disposition: attachment; filename="rachk.txt"

--- genfs_vnops.c.~1.92.~	Tue Jan  4 12:49:29 2005
+++ genfs_vnops.c	Mon Jan 17 18:21:41 2005
@@ -903,6 +903,10 @@ raout:
 		    genfs_rapages);
 		rasize = rapages << PAGE_SHIFT;
 		for (i = skipped = 0; i < genfs_racount; i++) {
+
+			if (raoffset >= memeof)
+				break;
+
 			err = VOP_GETPAGES(vp, raoffset, NULL, &rapages, 0,
 			    VM_PROT_READ, 0, 0);
 			simple_lock(&uobj->vmobjlock);

--==_Exmh_21096844084680--