From owner-freebsd-hackers Fri Apr 4 10:13:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id KAA23489 for hackers-outgoing; Fri, 4 Apr 1997 10:13:48 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id KAA23481 for ; Fri, 4 Apr 1997 10:13:45 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA19541; Fri, 4 Apr 1997 10:54:19 -0700 From: Terry Lambert Message-Id: <199704041754.KAA19541@phaeton.artisoft.com> Subject: Re: kern/3184: vnodes are used after they are freed. (dup alloc?) To: Tor.Egge@idi.ntnu.no (Tor Egge) Date: Fri, 4 Apr 1997 10:54:19 -0700 (MST) Cc: dfr@nlsystems.com, dg@root.com, ponds!rivers@dg-rtp.dg.com, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199704041627.SAA07632@pat.idt.unit.no> from "Tor Egge" at Apr 4, 97 06:27:18 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > 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.