From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 2 12:51:03 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 34FBB16A420; Thu, 2 Mar 2006 12:51:03 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [195.245.194.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D92543D46; Thu, 2 Mar 2006 12:50:41 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm513-1.comsys.ntu-kpi.kiev.ua (pm513-1.comsys.ntu-kpi.kiev.ua [10.18.52.101]) (authenticated bits=0) by comsys.ntu-kpi.kiev.ua (8.12.10/8.12.10) with ESMTP id k22D3WVO008562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Mar 2006 15:03:33 +0200 (EET) Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id C03FB5C024; Thu, 2 Mar 2006 14:50:43 +0200 (EET) Date: Thu, 2 Mar 2006 14:50:43 +0200 From: Andrey Simonenko To: John Baldwin Message-ID: <20060302125043.GA1682@pm513-1.comsys.ntu-kpi.kiev.ua> References: <200602281333.49277.jhb@freebsd.org> <20060301140635.GA669@pm513-1.comsys.ntu-kpi.kiev.ua> <200603011054.50628.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603011054.50628.jhb@freebsd.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV 0.82/1293/Sun Feb 19 18:40:25 2006 on comsys.ntu-kpi.kiev.ua X-Virus-Status: Clean Cc: freebsd-hackers@freebsd.org Subject: Re: Accessing address space of a process through kld!! 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, 02 Mar 2006 12:51:03 -0000 On Wed, Mar 01, 2006 at 10:54:49AM -0500, John Baldwin wrote: > > I have two questions about this function: > > > > 1. vm_fault() does not guarantee, that (possibly) faulted in page > > will be in the object or in one of backing objects when > > vm_fault() returns, because a page can become not resident > > again. Why not to wire needed page in vm_fault() (by giving > > a special flag to vm_fault() function)? > > > > 2. When the object which owns the page is unlocked, which lock > > guarantees, then m will point to a page? I mean m, which is > > used in vm_page_hold(m), which is called after VM_OBJECT_UNLOCK() > > (I mean a gap of time between VM_OBJECT_UNLOCK() and > > vm_page_lock_queues() function calls). > > > > Can you answer these two question? Thanks. > > Those are outside of my realm of knowledge unfortunately, but there are > some other folks you can ask including probably truckman@ and alc@. I'll wait some time for answers and may be will ask them directly in a private mail. Probably I need to create situation to force proc_rwmem() to make possibly incorrect step. Less than one year ago I found several bugs in FreeBSD VM subsystem (I found that bugs from theoretical understanding how everything works). Then I wrote userland programs to simulate that bugs. With one test program VM simply incorrectly worked and with another test program VM panics. I sent two comments about this to hackers@ mailing list, but haven't received any response (I just asked to give more strict description of VM semantics). (in groups.google.com type "wired shared comments freebsd" and see two comment in the top of the search results) ---------------------------- I see similar problems (?) as I described above in another parts of the system. For example vfs_export.c:vfs_export_lookup() function references np after releasing lock on head of corresponding PATRICIA tree: RADIX_NODE_HEAD_LOCK(rnh); np = (struct netcred *) (*rnh->rnh_matchaddr)(saddr, rnh); RADIX_NODE_HEAD_UNLOCK(rnh); if (np && np->netc_rnodes->rn_flags & RNF_ROOT) np = NULL; Also references to heads of PATRICIA trees are not protected by any lock. I think that everything works, because there is another mutex which protects these structures. For example Giant is acquired in nfs_srvsubs.c:nfsrv_fhtovp() before calling VFS_CHECKEXP and it is also acquired at some point in mount() path and lock on it occasionally is not lost in another function, for example in msleep().