Bug in VM pages protection handling.
Alan L. Cox
alc at imimic.com
Tue Jul 15 02:06:33 PDT 2003
Pawel Jakub Dawidek wrote:
>
> 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...
>
Could you post a pointer to the kernel module's source code?
Alan
More information about the freebsd-hackers
mailing list