Date: Wed, 20 Sep 2000 07:12:37 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mbendiks@eunet.no (Marius Bendiksen) Cc: tlambert@primenet.com (Terry Lambert), stein@eecs.harvard.edu (Christopher Stein), freebsd-fs@FreeBSD.ORG Subject: Re: how mmap buffer writes handled? Message-ID: <200009200712.AAA00357@usr05.primenet.com> In-Reply-To: <Pine.BSF.4.05.10009200903040.30002-100000@login-1.eunet.no> from "Marius Bendiksen" at Sep 20, 2000 09:04:32 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > use some of the protection facilities or such to force an exception to be > > > raised when accessing the page for write, and updating the statistics > > > based on that. > > as being dirty. If you look at the VM code, you will see that > > the page is actually mapped elsewhere, and the page not present > > fault is trapped, and then looked up in a translation table, 8-p. > > Indeed, so it does. But why would we have code to handle this on i386? Per my original post, the reason is that a kernel write fault, such as might happen as the result of a file read into an address in an mmap()'ed area, will fail to cause the page in question to be marked dirty, without this hack, and VM coherency will fail to be maintained. Failure of VM coherency is bad. > (PS: The method you mentioned would still qualify as "force an exception > to be raised when accessing the page for write" ;) Actually, not. It's on the order of the F00F bug fix, which is a gross kludge of the worst sort. The page being written doesn't exist. It's a non-existance exception, not an access exception, since if the page mapping existed, it wouldn't result in the exception in the first place. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009200712.AAA00357>