Date: Mon, 28 Jun 1999 12:54:12 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: "Daniel J. O'Connor" <darius@dons.net.au>, freebsd-hackers@FreeBSD.ORG, Ladavac Marino <mladavac@metropolitan.at> Subject: Re: RE: Implementation of mmap() in FreeBSD Message-ID: <199906281954.MAA24312@apollo.backplane.com> References: <Pine.GSO.3.96.990628145553.20294A-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> it is extremely memory efficient.
:
:I guess you are talking about VMIO buffers where the pages are found and
:registered into the buffer header during allocbuf(). When we do I/O on
:VMIO buffers using conventional system call method, we specify UIO_NOCOPY
:to instruct the uiomove() do not perform data copy.
UIO_NOCOPY is used to handle a degenerate case in the VFS/BIO vs VM
interaction for I/O, it has nothing to do with the read() or write()
syscall per say, nor is it related to the mmap code.
:> Programmers who use mmap() expect it to be as close to optimal as
:> possible.
:
:I write a program to test the mmap() today. It turns out that a user can
:modify the part of the mmapped area that is within the system returned
:area but not part of the user-specified area.
:
:As I understand it, there are two access paths to a file: conventional I/O
:through read/write systems calls and memory-mapped I/O. Both of them
:converge at the vnode read and write routine (VOP_READ() and VOP_WRITE()).
:This should give us the opportunity to guard against illegal memory-mapped
:I/O writes made by the user.
They converge in the VMIO page cache.
:Maybe we can add some fields in the vm_object to record the real or
:user-specifed area which can be passed to the vnode read and write
:routine. In the vnode I/O routine, we should be able to limit the write to
:only the orginal part of the area specified by the user. This practice
:should not incur any performance loss.
:
:-Zhihui
mmap bypasses the vnode. What you propose will not work because even if
the VM object is process-specific, the pages underlying the VM object are
not. If several processes are mmap()ing overlapping portions of the file,
they are *sharing* the pages. So even though they are not sharing the
VM object, the VM system will not be able to tell which process modified
the page, and therefore any byte-ranged limits specified in the VM object
will be useless.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199906281954.MAA24312>