Date: Mon, 5 Jun 1995 12:08:31 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Cc: davidg@root.com, hackers@freebsd.org Subject: Re: races in ufs_rename() Message-ID: <199506050208.MAA11426@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> ufs_rename() tries hard to avoid races and deadlocks. I think it fails >> to avoid serious races in 2 places: >> ... >It needs to do target lookup + lock, then source lookup + lock in that >order, instead to close the race. That's what it does, sort of. It locks the target file and its parent directory. It locks the source file when necessary. It can't lock the parent directory of the source because this might cause deadlock (for `mv a/a1 b/b1 && mv b/b2 a/a2'). It would be much simpler if it could lock this directory throughout. >The target should remain locked. This is easier said than done. >A path compare to determine if one is a substring of the other could >be done for ordering, and fail for EISDIR. Erm, string compares are useless because of aliases from symlinks and from "./././././." == ".". They can only work if both paths are simultaneously canonicalized. This seems to require holding locks on the parent directories all the way up to the root for the comparison and on all the parent directories of the target for a little longer. This may cause deadlock. The current method is better. ufs_checkpath() essentially canonicalizes the target path by following ".." links like getcwd(), but it works with inodes so it doesn't need to find names for the path components or canonicalize the source path. I think it would be correct if it returned with all the parent directories of the target locked and ufs_rename() kept them locked until it is almost finished. Then the source can move to another directory, but it can't move above the target because _all_ the directories above the target are locked. I'm not sure if this locking can cause deadlock. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506050208.MAA11426>