From owner-freebsd-fs Sat Nov 16 3:32:59 2002 Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D51A337B401 for ; Sat, 16 Nov 2002 03:32:57 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5118243E75 for ; Sat, 16 Nov 2002 03:32:56 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA05947; Sat, 16 Nov 2002 22:32:46 +1100 Date: Sat, 16 Nov 2002 22:45:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "Vladimir B. Grebenschikov" Cc: fs@FreeBSD.ORG Subject: Re: Question about not locked vnode in VOP_RENAME In-Reply-To: <1037387476.1037.6.camel@vbook> Message-ID: <20021116221131.Q18243-100000@gamplex.bde.org> 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 On 15 Nov 2002, Vladimir B. Grebenschikov wrote: > int > VOP_RENAME(struct vnode *fdvp, struct vnode *fvp, > struct componentname *fcnp, struct vnode *tdvp, > struct vnode *tvp, struct componentname *tcnp); > > It gets fdvp unlocked. Why it is differ from other similar VOPs. It must be left unlocked to avoid deadlock. > What will happens if between VOP_LOOKUP and VOP_RENAME > another VOP_LOOKUP will happens, say for for file removal in same > directory ? Nothing bad should happen. If applications race each other renaming and/or unlinking files, then the files may end up in unexpected places depending on who loses the races, but the results should not be worse because the races are lost inside of rename(2). E.g., in 2 interesting cases: (1) the "from" file gets completely unlinked (by another process). Then it will normally be relinked as the new "to" file. The result is the same as if the other process attempted to unlink it after it was renamed, except the unlink will fail with errno ENOENT. (2) the "from" file gets renamed to another file (possibly in a different directory) (by another process). Then the other file will normally be linked to the new "to" file (and it won't be unlinked by the rename). > Second lookup can destroy in-inode data (for ufs) saved by first lookup. Inodes can't be corrupted by changes to directory entries, except possibly as they reflect corruption of the directory tree. > It is seems that panics > http://spitfire.velocet.net/pipermail/freebsd-stable/2002-January/025074.html > http://docs.freebsd.org/mail/archive/1998/freebsd-current/19980913.freebsd-current.html > are because this race. The serious races in ufs_rename(), if any, are later. I think there is a serious one for the doingdirectory && newparent case. Then both the source and target need to be unlocked, so there is nothing to prevent arbitrary (non-corrupting) changes to the directory tree underneath us. I don't see how ufs_checkpath() + relookup() can handle all cases correctly (they should bail out if the directory tree changed too much). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message