Date: Sat, 16 Mar 1996 12:18:54 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: toor@dyson.iquest.net (John S. Dyson) Cc: terry@lambert.org, dawes@rf900.physics.usyd.edu.au, sos@FreeBSD.org, coredump@nervosa.com, mmead@Glock.COM, current@FreeBSD.org Subject: Re: -current and accelx Message-ID: <199603161918.MAA17675@phaeton.artisoft.com> In-Reply-To: <199603152223.WAA05025@dyson.iquest.net> from "John S. Dyson" at Mar 15, 96 10:23:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > In any case, you are not misinterpreting MAP_SHARED, IMO. > > It has been difficult to figure out what to do about this... What should > we do about MAP_SHARED mappings in the case of fork()? Note that MAP_PRIVATE > mappings are inherited (shared libs for example.) All mappings should be inherited across fork, but not across exec. The BSD-specific MAP_INHERIT is the only way to make mappings applicable across exec... and it is arguably a potential evil. Sun has "MAP_PRIVATE" and "MAP_SHARED". One of the two *must* be specified, and all they do is indicate the disposition of write requests: the object is copied so the changes affect one process, or the object is updated, so the changes affect both. Sun also has two flags: "MAP_FIXED" (an attach flag; same as the FreeBSD documentation) and "MAP_NORESERVE". By default, a mapping of MAP_PRIVATE reserves swap space equal to the size of the mapping; this is kind of a stupid option on an otherwise memory-overcommit architecture. If you MAP_NORESERVE and there isn't memory left, a write causes a SIGBUS, otherwise they are allocated at write time instead of being reserved. Sun's fork() causes swap space to be reserved for all private pages that exist in the parent so that copy-on-write will not fail for those pages (again, a stupid idea in an otherwise memory overcommit architecture -- if there is one hole in your reserve protocol, there is no reason to plug other holes of exactly the same character). Partial pages at the end of a mapping are zero-filled by the OS. We do this too, so that's one potential incompatability we don't have to worry about. One potential screw-up here is that the pages at the end of the mapping might become not zero-filled when the file is extended -- could this be one of the problems in INN? I think the mapping must preserve it's "zero-filled-ness", so the file write should force the mapping owner to create a private copy with the zero fill in it? I think Sun screwed up in making MAP_PRIVATE of pages without the PROT_WRITE bit reserve swap (there's no reason: writes aren't allowed, so there will never be a copy-on-write fault). I have no idea of how to safely handle mmap'ing on 386's, which don't support the write protect bit. Probably it will require a two stage mapping and unmapping the page and handling it in the fault (similar to the copy-on-write implementation for non-mapped pages). Are most of the problems sowing or are they non-existant on 386's specifically? In any case, we will need the ability to MAP_SHARED, !PROT_WRITE|PROT_EXEC for shared library text, but MAP_PRIVATE and PROT_READ|PROT_WRITE for shared library data for ELF, I think. The first case is the same in BSD shared libs. Anyway, that's all the musing I've done so far... 8-). 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?199603161918.MAA17675>