Skip site navigation (1)Skip section navigation (2)
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>