From owner-freebsd-fs Wed Jun 19 17:25:59 2002 Delivered-To: freebsd-fs@freebsd.org Received: from viola.sinor.ru (viola.sinor.ru [217.70.106.9]) by hub.freebsd.org (Postfix) with ESMTP id 4CF5B37B411; Wed, 19 Jun 2002 17:25:43 -0700 (PDT) Received: from p98.tc1.snt.ru (p98.tc1.snt.ru [217.70.126.98]) by viola.sinor.ru (8.9.3/8.9.3) with ESMTP id HAA21225; Thu, 20 Jun 2002 07:24:22 +0700 Date: Thu, 20 Jun 2002 07:26:41 +0700 (NOVST) From: "Semen A. Ustimenko" X-X-Sender: semenu@def.the.net To: Joseph Scott Cc: Boris Popov , , Subject: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) In-Reply-To: <20020614064339.K3828-100000@def.the.net> Message-ID: <20020620070637.P3227-100000@def.the.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi! Sorry for not fully investigated reply. There is no other problem in UFS, than that it hides the problem because it allows recursive lock to happen instead of ``locking against myself'' panic. The kern/37270 problem is in NULLFS. Step-by-step: NULLFS disregard LK_DRAIN flag. This means that the vnode may be successfully vclean()ed while some process was just sitting in vrele()->VOP_LOCK()->null_lock()->lockmgr(vp->v_vnlock) The above is exactly what leads to deadlock reported in PR, because when the lockmgr() exits, the nullfs vnode is already destroyed! Even though VOP_INACTIVE() is called, it can't unload the shared v_vnlock :( If anybody have ideas about how to fix this, please do not hesitate to share, but I can prevent you, that as soon as you begin to honor the LK_DRAIN flag, you immediately hit the deadlock I reported some time before. (IMHO, you don't hit it cause you usually win the race, but LK_DRAIN is born to loose it) Bye! On Sat, 15 Jun 2002, Semen A. Ustimenko wrote: > Hi! > > On Thu, 13 Jun 2002, Joseph Scott wrote: > > > On Thu, 13 Jun 2002, Semen Ustimenko wrote: > > > > # semenu 2002/06/13 10:30:40 PDT > > # > > # Modified files: > > # sys/fs/nullfs null_vnops.c > > # Log: > > # Fix wrong locking in null_inactive and null_reclaim. This makes nullfs > > # relatively working back. > > # > > # Reviewed by: mckusick, bp > > > > Any chance that this fix addresses PR kern/38107 (Panic on > > nullfs) or kern/37270 (nullfs broken by locking changes)? Unfortunately I > > don't understand what's involved here. These were the only two PR that > > mentioned nullfs that looked like they might be related to this commit. > > > Partially... > > kern/37270: This patch fixes the bug introduced in r1.51, but not the > problem with SHARED_LOOKUP. > > kern/38107: The panic is because v_rdev get dereferenced. It's not quite > clear to me how to create shadow vnode for spec vnode, neither if it is > necessary at all. > > I've just verified your method to deadlock, and it worked nicely (I mean > deadlocked nicely :). Here is what I found: > > When looking up the DOTDOT, in vfs_cache_lookup(), we VOP_UNLOCK() > parent directory, this is quite right... But the directory remains locked, > because it was recursively locked! This leads to deadlock... > > UFS allows the vnodes to be recursively locked and it seems that > softupdates require this. UFS gurus? > > Bye! > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message