Date: Mon, 12 Aug 1996 13:47:58 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrcpu@cdsnet.net (Jaye Mathisen) Cc: joerg_wunsch@uriah.heep.sax.de, freebsd-hackers@FreeBSD.ORG, proff@suburbia.net Subject: Re: mmap #2 Message-ID: <199608122047.NAA26050@phaeton.artisoft.com> In-Reply-To: <Pine.NEB.3.95.960812104110.22212M-100000@mail.cdsnet.net> from "Jaye Mathisen" at Aug 12, 96 10:42:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I think it was the other way around, it was truncating a mmap'd file. > > Specifically, I had problems when the active file shrunk after an rmgroup, > then I would get weird behaviour. John said he saw where that could > potentially be problematic, but I never saw any fixes run by that > addressed it by name. The question, of course, is what the heck does it mean when you mmap a file. If you interpret it as "provide page mappings into the address space of the process which made the mmap call equivalent to the size of the file at the time of the call", then you are asking for the page references to stay around, regardless of the fd-arbitrated file size. The problem is that if you truncate and automatically crop back the mapping following the truncation, shouldn't you also automatically increase the mapping in the extend case? The manual page is ambiguous as to what should happen to the address space on truncation. The implication of the interface is that the "len" parameter dictates that the size of the mapping object should be independent of the size of the file object. There is also an ambiguity with regard to "offset + len" being in excess of the file size. Finally, the documentation says "at most len bytes" instead of simply "len bytes", which implies that the mapped region is permitted to fall short of the actual mapping request when the file is smaller. Technically, the correct mechanism to eliminate all ambiguity would be to unmap , change the file size, and remap, for each time the file size is to be changed. This is true of Solaris, SunOS, and AIX, as well, where there are version dependencies on degree of VM and buffer cache unification, which can not be accounted for in any other way besides unmap, change, map. I would say that it is probably desirable to truncate the mapping region to the limit of the file length minus offset for the length requested, and adjust it up as the file is modified, until there are offset + len bytes mapped. This would require saving the value of the mapping request (perhaps 0 len should be the same as "dynamic" in this context, or (off_t)-1 (assuming 64 bit values are correctly sign-extended). I reiterate, however: this is not the current documented, nor expected behaviour, and further, you could only expect this behaviour on a machine where the VM and buffer cache were unified. For instance, the "failure" of some systems without a unified VM and buffer cache to do a read via fd of a page written via writing to a mapped page is to be expected when there is no protected mode write fault and a memory object is not being manipulated by a handle in such a way that the kernel can trap the manipulation in software (ie: copyin/copyout). Example: A 386 system will not honor the "Write Protect" bit of the MMU in protected mode, and will not generate a write fault to allow the buffer cache contents to be updated when the VM buffer is written through a valid user addressing. To resolve this, the page would have to be unmapped, generating a segmentation fault when written, and the fault handler would have to determine that it was an attempt to write page that is there, but which needs to generate a write fault call o the cache synchronization handler. It's possible to do this in a split cache environment, but it makes writing to mapped memory prohibitively expensive. In my opinion, it's INN at fault, not the OS's on which it runs; whoever wrote the mmap support didn't understand that they should use an mmap interface completely independent of using the fd insterface, since they could not depend on them being able to interoperate. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608122047.NAA26050>