Hi Roger,
I'm gonna be rude and fwd your mail to the list - in the hope
someone there will be able to help you. I'm running out of time
@sgi and have a bunch of stuff still to get done before I skip
outta here - having to look at the xfs_rename locking right now
might just be enough to make my head explode. ;)
cheers.
----- Forwarded message from Roger Willcocks <roger@xxxxxxxxxxxxxxxx> -----
Date: 05 Sep 2006 14:30:30 +0100
To: nathans@xxxxxxx
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
From: Roger Willcocks <roger@xxxxxxxxxxxxxxxx>
Subject: race in xfs_rename?
Hi Nathan,
I think I must be missing something here:
xfs_rename calls xfs_lock_for_rename, which i-locks the source file and
directory, target directory, and (if it already exists) the target file.
It returns a two-to-four entry list of participating inodes.
xfs_rename unlocks them all, creates a transaction, and then locks them
all again.
Surely while they're unlocked, another processor could jump in and
fiddle with the underlying files and directories?
--
Roger
----- End forwarded message -----
--
Nathan
|