Date: Sat, 15 Jun 2002 00:05:18 +0700 (NOVST) From: "Semen A. Ustimenko" <semenu@FreeBSD.org> To: Joseph Scott <joseph@randomnetworks.com> Cc: freebsd-fs@FreeBSD.org, <jeff@FreeBSD.org> Subject: UFS dotdot lookup deadlock (Was: Re: cvs commit: src/sys/fs/nullfs null_vnops.c) Message-ID: <20020614064339.K3828-100000@def.the.net> In-Reply-To: <Pine.BSF.4.21.0206131635250.9190-100000@pebkac.owp.csus.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020614064339.K3828-100000>