Bug in VM pages protection handling.
Pawel Jakub Dawidek
nick at garage.freebsd.pl
Tue Jul 15 01:51:48 PDT 2003
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 pawel at dawidek.net
UNIX Systems Programmer/Administrator http://garage.freebsd.pl
Am I Evil? Yes, I Am! http://cerber.sourceforge.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 305 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20030715/c9472f1e/attachment.bin
More information about the freebsd-hackers
mailing list