Date: Sat, 16 Nov 2002 22:45:28 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "Vladimir B. Grebenschikov" <vova@sw.ru> Cc: fs@FreeBSD.ORG Subject: Re: Question about not locked vnode in VOP_RENAME Message-ID: <20021116221131.Q18243-100000@gamplex.bde.org> In-Reply-To: <1037387476.1037.6.camel@vbook>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021116221131.Q18243-100000>