From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 15 01:51:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63AA037B401; Tue, 15 Jul 2003 01:51:48 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A39443F75; Tue, 15 Jul 2003 01:51:46 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 9260A3ABB51; Tue, 15 Jul 2003 10:57:21 +0200 (CEST) Date: Tue, 15 Jul 2003 10:57:21 +0200 From: Pawel Jakub Dawidek To: das@freebsd.org Message-ID: <20030715085721.GJ4973@garage.freebsd.pl> References: <20030712202216.GG4973@garage.freebsd.pl> <3F10762E.D17A7307@imimic.com> <20030712213249.GJ4973@garage.freebsd.pl> <20030715080501.GA34504@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Hc9bqgA2GpWXzMYS" Content-Disposition: inline In-Reply-To: <20030715080501.GA34504@HAL9000.homeunix.com> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: "Alan L. Cox" cc: freebsd-hackers@freebsd.org Subject: Re: Bug in VM pages protection handling. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 08:51:48 -0000 --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--