From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 31 11:03:30 2005 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 BD2B616A4CE for ; Thu, 31 Mar 2005 11:03:30 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C65243D4C for ; Thu, 31 Mar 2005 11:03:21 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)j2VB76iX059257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2005 14:07:07 +0300 (EEST) Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 22CD7371; Thu, 31 Mar 2005 14:02:55 +0300 (EEST) Date: Thu, 31 Mar 2005 14:02:54 +0300 From: Andrey Simonenko To: freebsd-hackers@freebsd.org Message-ID: <20050331110254.GA340@pm514-9.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on comsys.ntu-kpi.kiev.ua X-Virus-Scanned: ClamAV 0.82/791/Sun Mar 27 00:26:49 2005 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Subject: Comments about vm_fault, vm_map_lookup and user-wired memory, part 1 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: Thu, 31 Mar 2005 11:03:30 -0000 Greetings, I have two questions or comments about of user-wired memory (system 5.3). First question. If memory is user-wired, read-only and COW, then it is impossible to change protection for this memory: 1. mprotect() calls vm_map_protect(), which change entry->protection to writeable. 2. When write page fault occurs for this memory, vm_fault() calls vm_map_lookup(), which notices that entry->protection allows write to this memory (first if() statement in vm_map_lookup()), but, then it does not allow write page fault, since flag VM_PROT_OVERRIDE_WRITE is not set, since this is a normal page fault from a process. As the result, we have KERN_PROTECTION_FAILURE. From the other side, if this user-wired (now read-write after mprotect() call) and COW memory is modified by debugger, which uses VM_PROT_OVERRIDE_WRITE or'ed with VM_PROT_WRITE, then vm_map_lookup() creates shadow object, which shadows original memory and new page is created in the new shadow object. Since vm_fault() was called without any *WIRE* bit, then new page in the shadow object becomes unwired. Then when process which has user-wired memory exits, vm_map_unwire() is called for a page in that shadow object, since its vm_entry has wired_count greater than 0, since new page for the shadow object was not wired we get panic from vm_page_unwire(), since vm_map_delete() -> vm_map_entry_unwire() -> vm_fault_unwire() does not expect to see shadow objects for wired vm_entry When another process exits we get panic in vm_page_free() from vm_object_backing_scan(), when shadow object and original object in a process with user-wired memory are collapsed in vm_object_collapse(), since shadow object has copy of a page of user-wired page, vm_object_backing_scan() frees wired page. Here is my question: why it is not allowed to change protection of user- wired, r/o and COW memory? If it is not allowed to create shadow objects for wired memory for the same process, why they are created with the help from the debugger? Note, that such behavior causes panic, because some parts of the VM system are not aware of shadow object for objects with user-wired pages. Second question in the next letter.