From owner-freebsd-hackers@FreeBSD.ORG Thu May 15 11:18:56 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 A13411065676 for ; Thu, 15 May 2008 11:18:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 3CA688FC1D for ; Thu, 15 May 2008 11:18:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JwbU5-000D2s-Rs for freebsd-hackers@freebsd.org; Thu, 15 May 2008 14:18:54 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4FBIocL070399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2008 14:18:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4FBIlg3099391; Thu, 15 May 2008 14:18:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4FBIlJZ099390; Thu, 15 May 2008 14:18:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 May 2008 14:18:47 +0300 From: Kostik Belousov To: Teemu Rinta-aho Message-ID: <20080515111847.GX18958@deviant.kiev.zoral.com.ua> References: <482C0E70.4020305@rinta-aho.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ny9pOG5CW+LNoymi" Content-Disposition: inline In-Reply-To: <482C0E70.4020305@rinta-aho.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 5e2df25549de819b25d1bfd51e9f52eb X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2822 [May 13 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release 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: Thu, 15 May 2008 11:18:56 -0000 --Ny9pOG5CW+LNoymi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 15, 2008 at 01:20:32PM +0300, Teemu Rinta-aho wrote: > Hi all, >=20 > is it possible to create a memory object that represents > anonymous memory pages *and* is copy-on-write? >=20 > I have this code in a kernel module: >=20 > object =3D vm_object_allocate(OBJT_DEFAULT, 1); >=20 > result =3D vm_map_find(vmmap_proc, > object, > 0, > &addr, > len, > TRUE, > VM_PROT_ALL, > VM_PROT_ALL, > MAP_COPY_ON_WRITE); >=20 > Then I pass the addr to the user space, but when > I write to the addr, I see no shadow objects created, > i.e. the changes are written to the original memory > pages no matter if I have the map entry set as > copy-on-write or not... I am assuming a write fault would > create a new page and hang it to a shadow object thus > leaving the original memory untouched. >=20 > I'd appreciate any kind of help here. I cannot get a complete handle on your problem without full code, but I guess that you have only one reference to the backing object through the vm map entry. If this is the case, then the shadow copying actually does not make sense since no other users of the object need it. Look at the vm_object_shadow(), check at the start of the function. --Ny9pOG5CW+LNoymi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgsHBcACgkQC3+MBN1Mb4iIgACgoPCEMrYPXQikN3G2neX51+jR txUAn0JJMcoPypfEXwium413Sp7Ratpt =YxN0 -----END PGP SIGNATURE----- --Ny9pOG5CW+LNoymi--