From owner-freebsd-fs Wed Jun 19 22:44:27 2002 Delivered-To: freebsd-fs@freebsd.org Received: from yello.shallow.net (yello.shallow.net [203.18.243.120]) by hub.freebsd.org (Postfix) with ESMTP id 1116437B40E; Wed, 19 Jun 2002 22:44:22 -0700 (PDT) Received: by yello.shallow.net (Postfix, from userid 1001) id 861C52A6B; Thu, 20 Jun 2002 15:44:13 +1000 (EST) Date: Thu, 20 Jun 2002 15:44:13 +1000 From: Joshua Goodall To: "Semen A. Ustimenko" Cc: Joseph Scott , Boris Popov , freebsd-fs@FreeBSD.org, jeff@FreeBSD.org Subject: Re: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) Message-ID: <20020620054413.GA82672@roughtrade.net> References: <20020614064339.K3828-100000@def.the.net> <20020620070637.P3227-100000@def.the.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020620070637.P3227-100000@def.the.net> User-Agent: Mutt/1.3.28i 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 Semen, It's probably worth appending to 37270, then; my original diagnoses confused the 1.51 bugs with the drain bugs during an investigation of the LOOKUP_SHARED problems and clarity would be appreciated from someone with more VFS clue than I can currently bring on board. Regards Joshua On Thu, Jun 20, 2002 at 07:26:41AM +0700, Semen A. Ustimenko wrote: > 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 -- "Running makeworld fast is important to me. Anything longer than 5-10 minutes is too long, since it is not reasonable to check every commit using makeworld if it takes longer." - Bruce Evans, ultimate guardian of build stability. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message