From owner-freebsd-current  Wed Mar  6 13:27:38 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id NAA26326
          for current-outgoing; Wed, 6 Mar 1996 13:27:38 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA26315
          for <freebsd-current@FreeBSD.ORG>; Wed, 6 Mar 1996 13:27:31 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA07079; Thu, 7 Mar 1996 08:24:45 +1100
Date: Thu, 7 Mar 1996 08:24:45 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199603062124.IAA07079@godzilla.zeta.org.au>
To: bde@zeta.org.au, terry@lambert.org
Subject: Re: fixes for rename panic (round 1)
Cc: freebsd-current@FreeBSD.ORG, jhay@mikom.csir.co.za
Sender: owner-current@FreeBSD.ORG
Precedence: bulk

>Have you tested these changes with MDOSFS (especially) and EXT2FS
>(less especially)?

No.  These fixes can't possible affect msdsofs since they are in
ufs_rename() and msdosfs uses msdosfs_rename().  ext2fs uses
ufs_rename() almost directly and should benefit from the changes,
but I haven't tested it.  msdosfs_rename() must make its own
arrangement to handle the initial race (fvp == tvp), reference
counting for relookup(), and races involving relookup().  It
currently gets everything wrong.  E.g., msdosfs doesn't have links,
so (fvp == tvp) "can't happen", so it isn't handled.  However, it
happens because of the race in rename().

>I suspect a potential deadlock on identical
>path prefixes one path component off, and on "." and ".." references
>for some particular cases.

I think the potential for deadlock is avoided by not locking fdvp/fvp,
in rename(), and similar things in xxx_rename() (unlocking everything
before calling relookup() and xxxcheckpath()).  This costs a lot of
complexity to handle the resulting races.

>The existance of the race on the rename is intentional based on the
>need to hold the directory exclusively when inserting an entry.

No, it's because of the potential for deadlock if the `from' and the
`to' directory entries and parent directories are all locked at once.
fdvp/fvp are intentionally left unlocked so that deadlock can't occur.
This creates problems later.  The most complicated case is moving a
directory to a new parent directory.  As well as there being more links
to change in this case, everything is unlocked so it it is possible for
both the source and the destination directory entries and parent
directory entries to vanish.

Bruce