From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 15 02:06:33 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 96D3C37B401 for ; Tue, 15 Jul 2003 02:06:33 -0700 (PDT) Received: from mail26c.sbc-webhosting.com (mail26c.sbc-webhosting.com [216.173.237.166]) by mx1.FreeBSD.org (Postfix) with SMTP id 77B8E43F85 for ; Tue, 15 Jul 2003 02:06:32 -0700 (PDT) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21)3-0634799978; Tue, 15 Jul 2003 05:06:18 -0400 (EDT) Sender: alc@FreeBSD.ORG Message-ID: <3F13C40A.E2ACE104@imimic.com> Date: Tue, 15 Jul 2003 04:06:18 -0500 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20030712202216.GG4973@garage.freebsd.pl> <3F10762E.D17A7307@imimic.com> <20030712213249.GJ4973@garage.freebsd.pl> <20030715080501.GA34504@HAL9000.homeunix.com> <20030715085721.GJ4973@garage.freebsd.pl> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 cc: freebsd-hackers@freebsd.org cc: das@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 09:06:33 -0000 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