Date: Thu, 20 Jun 2002 07:26:41 +0700 (NOVST) From: "Semen A. Ustimenko" <semenu@FreeBSD.org> To: Joseph Scott <joseph@randomnetworks.com> Cc: Boris Popov <bp@butya.kz>, <freebsd-fs@FreeBSD.org>, <jeff@FreeBSD.org> Subject: NULLFS PRs (Was: Re: UFS dotdot lookup deadlock) Message-ID: <20020620070637.P3227-100000@def.the.net> In-Reply-To: <20020614064339.K3828-100000@def.the.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020620070637.P3227-100000>