From owner-freebsd-hackers Mon Jun 28 13:14: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sol (cs1-gw.cs.binghamton.edu [128.226.171.72]) by hub.freebsd.org (Postfix) with SMTP id AF8081538C for ; Mon, 28 Jun 1999 13:13:47 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from localhost (zzhang@localhost) by sol (SMI-8.6/8.6.9) with SMTP id QAA20625; Mon, 28 Jun 1999 16:01:42 -0400 Date: Mon, 28 Jun 1999 16:01:42 -0400 (EDT) From: Zhihui Zhang To: Matthew Dillon Cc: "Daniel J. O'Connor" , freebsd-hackers@FreeBSD.ORG, Ladavac Marino Subject: Re: RE: Implementation of mmap() in FreeBSD In-Reply-To: <199906281954.MAA24312@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 28 Jun 1999, Matthew Dillon wrote: > :> 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. By converge, I mean VOP_GETPAGES() and VOP_PUTPAGES() will call VOP_READ() and VOP_WRITE() just as read() and write() system call. > > :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. This is a good point! I have never thought of it before. Thanks. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message