[ovs-dev] Bug#681880: [bug 681880 1/3] lockfile: Fix hang locking through a dangling symlink.

[Bastian Blank]

On Thu, Jul 26, 2012 at 11:53:25PM -0700, Ben Pfaff wrote:
> On Fri, Jul 27, 2012 at 08:39:42AM +0200, Bastian Blank wrote:
> > I would always use the lock file at the target location of the database
> > and not follow symlinks there. Otherwise more than one lock file can
> > exist.
> We have to follow symlinks, so that the lock file ends up in /var/lib,
> because FHS says that /etc is static, and therefore may be mounted
> read-only, and therefore we cannot create a read/write file there.

I was unclear. You should first use realpath(3) on the database filename
and calculate the lock file from there. Otherwise there may be several
lock files for the same db.

Also, I see no lstat or realpath calls, so using symlinks is not safe
anyway. The daemon does not know the real location to calculate the lock
and temp file locations.

> > On second thought, drop the lock file and use fcntl(db, F_SETLK…) on the
> > database file itself. This lock is automatically released if the process
> > dies.
> We cannot drop the lock file, because the lock file grants the right not
> merely to modify the database but to put another file in its place.
> That is, the locked entity is the name, not the inode to which the name
> refers.

This is no real problem. Obtaining an exclusive lock for the complete
file, not only parts, may include the right to replace it. This just
needs to be documented.

However the current solution alows for a disappearing lock file and
may corrupt the database in this case.

Bastian

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6