Date: Thu, 23 Sep 1999 12:37:27 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Kenneth D. Merry" <ken@kdm.org> Cc: cmsedore@mailbox.syr.edu (Christopher Sedore), freebsd-hackers@FreeBSD.ORG Subject: Re: mbufs, external storage, and MFREE Message-ID: <199909231937.MAA29808@apollo.backplane.com> References: <199909231924.NAA06294@panzer.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:How about marking the page copy-on-write? That way, if the user modifies
:the page while it is being transmitted, it'll just be copied, so the
:original data will be intact.
:
:Ken
If it were a normal page we could, but the VM system currently cannot
handle pages associated with vnodes themselves being marked copy-on-write.
This is kinda hard to explain, but I will try.
When a process maps a file MAP_PRIVATE, the VM object held by the process
is not actually a vnode. Instead it is holding what is called a
default object. The default object shadows the VM object representing
the vnode. When a fault occurs, vm_fault knows to copy-on-write the page
from the read-only backing VM object to the the front VM object and so
from the point of view of the process, the page is copy-on-write. From
the system's point of view, a new page has been added to the default
VM object and no changes have been made to the vnode's VM object.
When a process maps a file MAP_PRIVATE or MAP_SHARED and doesn't touch
any of the pages, and some other process goes in and write()'s to the
file via a descriptor, the process's view of the file will change
because the pages associated with the underlying vnode have changed.
The problem that occurs when we try to optimize read by mapping
a vnode's page into a user address space is that some other process
may go and modify the underlying file, modifying the data that the
user process sees *after* the read() has returned. But the user process
is expecting that data not to change because it thinks it has read() it
into a private buffer when, in fact, the OS optimized the read by replacing
the private memory with the file map.
i.e. our problem is not so much the user process making a change to its
buffer -- that case is handled by copy-on-write, but of another process
writing directly to the vnode causing the data the first process read()
to appear to change in its buffer.
-Matt
Matthew Dillon
<dillon@backplane.com>
:--
:Kenneth Merry
:ken@kdm.org
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909231937.MAA29808>