Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jul 2003 10:57:21 +0200
From:      Pawel Jakub Dawidek <nick@garage.freebsd.pl>
To:        das@freebsd.org
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Bug in VM pages protection handling.
Message-ID:  <20030715085721.GJ4973@garage.freebsd.pl>
In-Reply-To: <20030715080501.GA34504@HAL9000.homeunix.com>
References:  <20030712202216.GG4973@garage.freebsd.pl> <3F10762E.D17A7307@imimic.com> <20030712213249.GJ4973@garage.freebsd.pl> <20030715080501.GA34504@HAL9000.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Hc9bqgA2GpWXzMYS
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
+>=20
+> 1) The process forks
+>=20
+> 2) The child makes a system call that results in the creation of a
+>    new read-only map entry.
+>=20
+> 3) The parent calls mmap() (for example) to create a read-write
+>    map entry with the same virtual address.
+>=20
+> 4) Somehow the parent's permissions end up being read-only, not
+>    read-write, and the parent dies.
+>=20
+> 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...

--=20
Pawel Jakub Dawidek                       pawel@dawidek.net
UNIX Systems Programmer/Administrator     http://garage.freebsd.pl
Am I Evil? Yes, I Am!                     http://cerber.sourceforge.net

--Hc9bqgA2GpWXzMYS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iQCVAwUBPxPB8T/PhmMH/Mf1AQFNpQP/fhawR4pfMjB2bqS7KpeKY5MpNBsH1I4q
gk8807Rh2AeycEGD1j+Qsi4n7PJ29nYBcSvFw9esdfivLpBbIB6rdirRCvxFT7Mw
29faQUyDyHWP95qN8RNq6AShaXz4NGBWPAaRHNK+VDj8H3D+V5Pzs2kYT2Hn6sOo
Vj3ZG5puDII=
=fK1V
-----END PGP SIGNATURE-----

--Hc9bqgA2GpWXzMYS--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030715085721.GJ4973>