From owner-freebsd-hackers  Fri Apr  4 07:04:38 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id HAA12071
          for hackers-outgoing; Fri, 4 Apr 1997 07:04:38 -0800 (PST)
Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA12064
          for <freebsd-hackers@freebsd.org>; Fri, 4 Apr 1997 07:04:34 -0800 (PST)
Received: from idt.unit.no (26850@kamelia.idt.unit.no [129.241.111.27])
	by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id RAA05693;
	Fri, 4 Apr 1997 17:03:20 +0200 (MET DST)
Message-Id: <199704041503.RAA05693@pat.idt.unit.no>
To: dg@root.com
Cc: ponds!rivers@dg-rtp.dg.com, freebsd-hackers@freebsd.org
Subject: Re: kern/3184: vnodes are used after they are freed. (dup alloc?) 
In-Reply-To: Your message of "Thu, 03 Apr 1997 20:10:45 -0800"
References: <199704040410.UAA08780@root.com>
X-Mailer: Mew version 1.06 on Emacs 19.34.1
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Date: Fri, 04 Apr 1997 17:03:15 +0200
From: Tor Egge <Tor.Egge@idi.ntnu.no>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>    Uh, this is wrong since VOP_INACTIVE really wants a '0' usecount vnode,
> and there are assumptions throughout the code that a '0' usecount also
> implies that the vnode is on the free list. A quick code review of Tor's
> suggested fix shows that it will fail in several places in the kernel and
> basically needs to be re-thought...which is why it hasn't been committed
> yet.

I'm running with the modified suggested fix now, and have not seen any
failures due to that suggested fix. The original suggested fix failed
due to the assumptions that a `0' usecount meant that it was on the
free list, and a NULL pointer was dereferenced when trying to move the
vnode to the head of the free list. Adding a kludge (magic number
0xdeadb, used elsewhere in the code to mark that the vnode was not on
the freelist) made the code work for my tests.

>    No, a vnode on the free list is always "free" - it will be removed from
> the free list prior to any I/O occuring. The only caveat to this is that
> entries in the namei cache can point to "free" vnodes and there is some
> kludgewear to deal with this.

The -current code calls VOP_INACTIVE on vnodes on the free list having
`0' as usecount, and fails when the vnode is reused for other purposes
while VOP_INACTIVE is blocked.

Before the Lite/2 merge, nfs_inactive did not try to unlock the node.
The vnode was probably not referenced after the blocking of
VOP_INACTIVE (due to nfs_removeit() blocking, waiting for RPC answer).

- Tor Egge