From owner-freebsd-current Tue Sep 10 12:37: 8 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D248637B400; Tue, 10 Sep 2002 12:37:04 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E16B743E6E; Tue, 10 Sep 2002 12:37:03 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g8AJZKOo025607; Tue, 10 Sep 2002 15:35:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 10 Sep 2002 15:35:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Lewis Cc: bde@zeta.org.au, current@FreeBSD.ORG, jeff@FreeBSD.ORG Subject: Re: vnode lock assertion problem in nfs_link() In-Reply-To: <200209101918.g8AJIHwr095835@gw.catspoiler.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 10 Sep 2002, Don Lewis wrote: > On 11 Sep, Bruce Evans wrote: > > On Tue, 10 Sep 2002, Don Lewis wrote: > > > > I have just one thing to add to Robert's reply. > > > >> BTW, is it safe to call ASSERT_VOP_UNLOCKED() in the SMP case after the > >> reference has been dropped with vput() or vrele()? > > > > I think it is. It has some internal locking (v_interlock at least), and > > only asserts that the vnode is unlocked by curthread so it doesn't matter > > if another thread locks it. > > I'm mostly worried about the vnode being recycled as something else > after the vput() or vrele() call. I think a better approach would be to > add the assertion checks to vput() and vrele(), which would mean that we > could remove most of the checks in the syscall code. The only problems > we would miss would be when we leak vnode references, but reference > leaks are a problem anyway. I wish there was a good way to add > assertion checks for detecting the leaks. Unfortunately, we can't assert not locked at the end of vput because of recursive locking of vnodes. What I would like to see is a check that, when control is returned to userland, that the thread owns no locks. It's a bit like sleeping while holding a mutex: don't do that. Also, last time I tried to use the ddb show lockedvnods command, I got the problem attached below due to locking issues, which makes it a lot harder to debug locking problems... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories db> show lockedvnods Locked vnodes panic: blockable sleep lock (sleep mutex) mountlist @ ../../../kern/vfs_subr.c:2621 Debugger("panic") Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc0423ed4 stack pointer = 0x10:0xc869b9d0 frame pointer = 0x10:0xc869b9dc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 11 (idle) Stopped at siointr1+0xf4: movl $0,brk_state1.0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message