On Tue, Jul 15, 2003 at 01:05:01AM -0700, David Schultz wrote: +> So let me see if I've got the sequence of events straight: +> +> 1) The process forks +> +> 2) The child makes a system call that results in the creation of a +> new read-only map entry. +> +> 3) The parent calls mmap() (for example) to create a read-write +> map entry with the same virtual address. +> +> 4) Somehow the parent's permissions end up being read-only, not +> read-write, and the parent dies. +> +> Is this correct? If so, this doesn't sound like a problem with +> vm_map_protect(), but rather with your handling of map entry +> sharing. My first inclination, as a non-expert, would be that +> you're not taking MAP_ENTRY_NEEDS_COPY into account. This is an +> optimization that allows two processes to share map entries until +> a COW fault is taken in one of them. This speeds up fork(2) +> greatly because VM objects are not allocated unnecessarily.
Not exactly. Every page was is marked by cerb as read-only is also allocated by cerb in process' vmspace, so IMHO such situation shouldn't occur. We got something like this: 1. The process forks. 2. New pages are allocated in child's vmspace and are marked as read-only. 3. I don't know exactly what happends with child, but parent dies. I've solve this problem by marking those pages back to VM_PROT_ALL after syscall is done. Is there a chance that parent reuse those pages somehow? Or those pages aren't removed and if parent want to allocate some memory he gets read-only page? But I don't think so... -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net
pgp00000.pgp
Description: PGP signature
