From owner-freebsd-current Wed Sep 13 08:46:32 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA14427 for current-outgoing; Wed, 13 Sep 1995 08:46:32 -0From owner-freebsd-current Wed Sep 13 10:47:01 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id KAA19240 for current-outgoing; Wed, 13 Sep 1995 10:47:01 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id KAA19234 for ; Wed, 13 Sep 1995 10:46:50 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA07728; Wed, 13 Sep 1995 10:41:43 -0700 From: Terry Lambert Message-Id: <199509131741.KAA07728@phaeton.artisoft.com> Subject: Re: BAD BUG IN UFS RENAME To: bde@zeta.org.au (Bruce Evans) Date: Wed, 13 Sep 1995 10:41:43 -0700 (MST) Cc: davidg@root.com, terry@lambert.org, current@freebsd.org, mckusick@mckusick.com In-Reply-To: <199509131058.UAA05201@godzilla.zeta.org.au> from "Bruce Evans" at Sep 13, 95 08:58:16 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 718 Sender: current-owner@freebsd.org Precedence: bulk > Nope, there are several known msdosfs rename bugs, all known to be > different. (E.g., one is also a ufs rename bug: things have to be unlocked > before calling checkpath() to avoid deadlock, but this allows races > in checkpath(). Bad effects are easy to demonstrate by putting a tsleep() > in checkpath() before the call to VFS_VGET() and removing a critical > file or directory during the simulated blockage of VFS_VGET().) I was wondering why the hell this was. As far as I can tell, ufs_rename() in ufs_vnops.c is the only consumer of ufs_checkpath() in ufs_lookup.c. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.