From owner-freebsd-current  Fri May  2 11:56:04 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA16208
          for current-outgoing; Fri, 2 May 1997 11:56:04 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA16161
          for <current@FreeBSD.ORG>; Fri, 2 May 1997 11:55:58 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA09219; Fri, 2 May 1997 11:54:24 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199705021854.LAA09219@phaeton.artisoft.com>
Subject: Re: vnode->v_usage
To: phk@dk.tfs.com (Poul-Henning Kamp)
Date: Fri, 2 May 1997 11:54:24 -0700 (MST)
Cc: dfr@nlsystems.com, phk@dk.tfs.com, current@FreeBSD.ORG
In-Reply-To: <5321.862569821@critter> from "Poul-Henning Kamp" at May 2, 97 12:43:41 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-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Ok, now I'm in doubt here...  Which of these two places are the
> correct place to release the interlock, I've marked the candidates
> with XXX, I pressume the later, right ?
> 
> 	void
> 	vtouch(vp)
> 		struct vnode *vp;
> 	{
> 		simple_lock(&vp->v_interlock);
> 		if (vp->v_usecount) {
> 			simple_unlock(&vp->v_interlock);
> 			return;
> 		}
> 		simple_unlock(&vp->v_interlock);  /* XXX */
> 		simple_lock(&vnode_free_list_slock);
> 		TAILQ_REMOVE(&vnode_free_list, vp, v_freelist);
> 		TAILQ_INSERT_TAIL(&vnode_free_list, vp, v_freelist);
> 		simple_unlock(&vnode_free_list_slock);
> 		simple_unlock(&vp->v_interlock);  /* XXX */
> 	}

The first place may allow the code to be reentered.

The second place may deadly-embrace deadlock during directory lookups
for open or elsewhere, though I can't tell you for sure.


Could you artifically bump the use count over the operation?  Hold
the interlock, bump the count, release the interlock, move the
vnode, hold the interlock, decrement the use count, release the
interlock?

The problem seems to be that you don't want the count going 0 without
the interlock held.  This way, it wouldn't.


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