Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Apr 1997 10:54:19 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        Tor.Egge@idi.ntnu.no (Tor Egge)
Cc:        dfr@nlsystems.com, dg@root.com, ponds!rivers@dg-rtp.dg.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: kern/3184: vnodes are used after they are freed. (dup alloc?)
Message-ID:  <199704041754.KAA19541@phaeton.artisoft.com>
In-Reply-To: <199704041627.SAA07632@pat.idt.unit.no> from "Tor Egge" at Apr 4, 97 06:27:18 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> When the vnode is on the freelist, with 0 as v_usecount, and the
> vp->v_interlock is not locked, how should getnewvnode decide that the
> vnode is not reusable ?  VOP_ISLOCKED ? Not currently used in
> getnewvnode nor in vget.

This is all terrible code, IMO.  It's both confusing, and totally
lacking in uniformity of application.

That said, you can test to see if the VFS the vnode references is
deadfs.  Vnodes which are invalid have deadfs as their VFS.

The problem with this is that the deadfs is an indicator of
invalidation of the vnode, not the fact that the vnode does not
have refernces to it (deadfs is specifically built to deal with
the now-invalid references by causing VOP calls on the vnode to
fail).

You should join the discussion on the -current list regarding this
issue.  Historically, I've seen the vclean() and the locking which
must be duplicated per FS as the primary evil.  I think maybe that
the vnodes need to be more carefully reference counted and released
on a per FS basis, and deadfs needs to go away.

This has a number of implications for kernel file I/O: if you take
away the ability to invalidate a vnode (by getting rid of deadfs,
and by eventually removing the ability to migrate a vnode between
FS types), then you need another mechanism to serve as a "handle"
for the vnode so that it can still be invalidated.  I'v nominated
the system open file table, and that's about where the discussion
currently stands: the merits and demerits of doing all this work,
and what we expect to get out of it.


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704041754.KAA19541>