From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 14:48:43 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF3C81065682 for ; Fri, 16 May 2008 14:48:43 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1DC8FC15 for ; Fri, 16 May 2008 14:48:43 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id m4GEY7DX082156; Fri, 16 May 2008 09:34:07 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1210948447; bh=ptgvQ+2vMeOhestrHt8AWrcMc9Q=; h=Date: From:Message-Id:To:Subject:Cc:In-Reply-To; b=NidSMw9NHNCZZPFIkoBeU PkrlpWNp7DkKniVr+YfwmsoKN/O22H+6ltnpvEpe6hex9B51axpKF9Zz899Q5NZj5m7 V2azbL5zbjR7K4zC3nqggyXBu/gHhdnD/hrE7yD5TFuKpPYcofERVJZa1NjX4uaqtAk fyd8KuphUOLMCin4= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id m4GEY6N3082155; Fri, 16 May 2008 09:34:06 -0500 (CDT) (envelope-from tinguely) Date: Fri, 16 May 2008 09:34:06 -0500 (CDT) From: Mark Tinguely Message-Id: <200805161434.m4GEY6N3082155@casselton.net> To: teemu@rinta-aho.org In-Reply-To: <482C4DF3.8030709@rinta-aho.org> X-Mailman-Approved-At: Fri, 16 May 2008 16:09:59 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: copy-on-write anonymous memory? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 14:48:43 -0000 Teemu Rinta-aho wrote (some edits): > I have created a kernel module that stores references to memory objects. > I.e. when a process makes a syscall to the module, it will create a > snapshot of the memory area, and after that the writes from the process to > that memory area should create a shadow object. The next syscall should > again store a pointer to the current topmost shadow object and then the > next write creates yet another shadow object. Etc... When the snapshots > are removed, the shadow chains may collapse normally. > > Here's an illustration of what I want (first syscall OK, second one not): > > * Legend: U/u = userspace K/k = kernel > * > * U:vm_map_entry_u -> object > * || > * SYSCALL > * || > * \/ > * U:vm_map_entry_u -> object_shadow -> object > * / > * K:vm_map_entry_k ---------------- > * || > * SYSCALL > * || > * \/ > * U:vm_map_entry_u -> object_shadow -> object_shadow -> object > * / / > * K:vm_map_entry_k ---------------- / > * K:vm_map_entry_k -------------------------------- > > Now, the problem is that the first snapshot works as it should. However, > the second one doesn't, and the write goes to the one and same shadow > object, even if I restore MAP_ENTRY_COW and MAP_ENTRY_NEEDS_COPY manually > in my handler function which is storing the snapshot. > > Any ideas? Usually, a fork() creates the inheritance between parent and child COW memory space. Start: vm_map_entry -> object_shadow -> object fork(): vm_map_entry -> object_shadow -\ |-> (object_shadow*) -> object vm_map_entry -> object_shadow -/ This is slightly different from your description/drawing, in the way changes are inherited; for example: process 1 is created, process 1 writes page 0. process 2 is created. process 1 writes p1 (or p0 again). Your description/drawing implies that process 2 see this change from process 1. You are not forking over a COW memory area. Sounds like the syscall will have manually create the inheritance. You can manually link the object_shadows the way you want to get the desired inheritance. Process removals should collapse the shadows automatically. Matt Dillion wrote a brief VM description (http://www.freebsd.org/doc/en_US.ISO8859-1/articles/vm-design/). The book, "The Design and Implementation of the 4.4BSD Operating System" is another great reference. Mark Tinguely