From owner-freebsd-fs Fri Jun 14 10: 5:28 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 92F0037B40E; Fri, 14 Jun 2002 10:05:22 -0700 (PDT) Received: from p113.c5350.sinor.ru (p113.c5350.sinor.ru [217.70.110.113]) by viola.sinor.ru (8.9.3/8.9.3) with ESMTP id AAA30590; Sat, 15 Jun 2002 00:03:22 +0700 Date: Sat, 15 Jun 2002 00:05:18 +0700 (NOVST) From: "Semen A. Ustimenko" X-X-Sender: semenu@def.the.net To: Joseph Scott Cc: freebsd-fs@FreeBSD.org, Subject: UFS dotdot lookup deadlock (Was: Re: cvs commit: src/sys/fs/nullfs null_vnops.c) In-Reply-To: Message-ID: <20020614064339.K3828-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! 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