Date: Thu, 2 Mar 2006 14:50:43 +0200 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Accessing address space of a process through kld!! Message-ID: <20060302125043.GA1682@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <200603011054.50628.jhb@freebsd.org> References: <cdc1d1310602270026o6b17101et14ddf301269edc37@mail.gmail.com> <200602281333.49277.jhb@freebsd.org> <20060301140635.GA669@pm513-1.comsys.ntu-kpi.kiev.ua> <200603011054.50628.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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().
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060302125043.GA1682>